Fix me if you can

Fix me, if you can

We prepared you a site to fix. It has been broken in many, many places. You will work in teams to fix it.

About the session

We are drupalists, consultants, working in the Acquia Professional Services team Alex Ku Balázs Dianiska Hernâni Borges de Freitas Théodore Biadala

About us

Alex

drupal.org: alexku linkedin: Alex Ku

Balázs

drupal.org: snufkin twitter: @thesnufkin

Hernâni

drupal.org: hernani twitter: @hernanibf

drupal.org: nod_ twitter: @nod_

Théodore

LAMP stack Varnish is installed and set up We set up a site for each team Each site is broken in many ways

What is in the box

15:45 - 16:00 - Introduction and setup 16:00 - 16:25 - Site building 16:25 - 16:35 - Break 16:35 - 17:00 - Security 17:00 - 17:10 - Break 17:10 - 17:35 - Performance 17:35 - 18:00 - Wrap up and questions

Lab schedule

http://fixme.acquia-ps.com

What we prepared: 1 site per team 1 login per site We can create 25 sites, so lets split into teams Address: http://fixme.acquia-ps.com Password will be on the site

Setup


Site building

•  Best practices §  Drupal coding standards §  Security §  Performance

•  Code architecture •  Content architecture •  Configuration


Review process

1.  Make the site run 2.  Run automated tools 3.  Triage the output 4.  Read all the custom code* 5.  Dig into messy areas


Tools

•  Update •  Hacked •  Coder •  PHP_CodeSniffer •  Insight •  A Brain


Red flags

•  PHP Filter module •  PHP in templates •  Many, many template files •  Many views/blocks/panels with a similar

name •  Many content types with one or two nodes


Exercise 1- Code hacked

•  Looking for hacked core / contrib •  Go to hacked report and run it


Exercise 2- Missing updates

•  Run Update module •  Explain how to keep it up to date


Exercise 3 - Coding standards

•  Coder & PHP Code Sniffer •  Find jquery_countdown and email_login_link


Exercise 4 - Views architecture

•  Check “News” views


Exercise 5 - Content architecture - article => 1320 - teaser => 805 - microsite => 273 - … - sports_homepage => 1 - teams_homepage => 1 - change_password => 1 - login_form => 1 - footer_homepage => 1


Secure your Drupal site by first hacking into it


Drupal vulnerabilities by popularity

reported in core and contrib SAs from 6/1/2005 through 3/24/2010

Access Bypass

http://www.flickr.com/photos/nikonvscanon/1816459664/

Access Bypass

“Inadequate or weak access control over a resource”

Authentication

Authorization

Access Bypass

When a user can

see something they shouldn’t

perform an action they shouldn’t

Stop Access Bypass

Implement checks

before providing an action

after undertaking an action

Access Bypass Hands-on

First as anonymous user goto: http://fixme.acquia-ps.com/[teamN]/admin/dashboard/users/all

What’s there: VBO allows sending an email to any address and blocking

users

How can we fix this?

Access Bypass Hands-on

The problem is in:

●  “Bypass views access control” permission

●  “Actions permissions (VBO)” module

http://www.flickr.com/photos/nathaninsandiego/3757033518/ http://flic.kr/p/6HZMaY

Cross Site Scripting

Cross Site Scripting

XSS

Javascript

Performing actions without your intent

Everything you can do XSS can do faster

Stored XSS Step 1

Drupal Attacker

Request

JS

DB JS


Stored XSS Step 2

Drupal Victim

Request

Response JS

JS

DB


Stored XSS Step 3

Drupal Victim Request

JS

DB

JS


$node = node_load($nid); $title = $node->title; drupal_set_title($title); ... (later, in page.tpl.php) ... <h1><?php print $title; ?></h1>


XSS Hands-on First as admin user go to:

http://fixme.acquia-ps.com/[teamN]/user/1 and notice value for Full Name

Then open this page:

http://fixme.acquia-ps.com/[teamN]/node/56

Now open the first page again and notice the Full Name has changed



XSS Hands-on

The problem is in:

●  Filtered HTML text format allowing <script> tag

●  Security Review module helps detecting issues like this


http://www.flickr.com/photos/jackofspades/4500411648/

Cross Site Request Forgery


CSRF

Taking action without confirming user intent


Attacker makes action occur on your behalf

Using your session

Without you knowing or approving


/comment/reply/1

Attacker

img src=delete/1

Drupal


Victim html

cookie

Drupal Drupal

/user/login


Victim Drupal Drupal

/node/1


Victim html Drupal Drupal

/node/1

/delete/1

validate intent

“Did the user mean to carry-out action” or “Could an attacker execute this on behalf of a user”

Protecting against CSRF

Something secret, unique to the action Shared between trusted user and server

Validate intent?

only if using Form API

generates form token

checks token when processing form

Drupal protects against CSRF with Form API

fancy AJAX, GET callbacks

drupal_get_token() drupal_valid_token()

Generate your own token

attacker identifies weak point gets authorized account to take action

protect by confirming intent


As anonymous user add a comment with an image like this:

<img src=”admin/content/unpublish/[nid]”>

Visit the page with the comment as admin

Check if the node is unpublished


CSRF Hands-on

A proper fix would require adding protection in callback function for path: admin/content/unpublish/[nid]

A quick fix would filter img tags in Filtered HTML

CSRF Hands-on

SQL Injection

Mixing data received from the user with database query allows an attacker to perform

custom actions against the database

As anonymous user go to:

http://fixme.acquia-ps.com/show/node?nid=[nid]

You should see a title and status of a single node

Now append this to the url: “ union select uid, name, status from users”

You should see names of all users

How can we detect and fix this?

SQL Injection Hands-on


Security Review module helps detect simple SQL injection vulnerabilities

Fixing this would require rewriting custom code

The vulnerable lines are: $nid = $_GET['nid']; $r = db_query("SELECT nid, title, status FROM {node} WHERE status = 1 AND nid = $nid");

The fix would look something like: $nid = $_GET['nid']; $r = db_query("SELECT nid, title, status FROM {node} WHERE status = 1 AND nid = :nid", array(“:nid” => $nid));


Automation

http://www.flickr.com/photos/hubmedia/2141860216/

Steps to a mostly automated review

Security Review: drupal.org/project/security_review

Hacked: drupal.org/project/hacked

Coder: drupal.org/project/coder

Secure Code Review

drupal.org/project/secure_code_review

Vuln: github.com/unn/vuln

HTML Purifier:

drupal.org/project/htmlpurifier

More: http://drupalscout.com/node/11

Performance


Slow? What you mean? •  Backend slowness

•  Services that website use are slow or unresponsive (dbs)

•  Application too complex

•  Server resources overload

•  Frontend slowness

•  Too many assets

•  Slow connection between browser and server.

•  JS slowing the DOM (re)rendering


Profile

Look for pages you suspect

•  Start by easy ones

•  404 page (the fastest page you can get).

•  Node view page

•  Homepage

•  Continue with the ones your data marked as slow.

Time for some research


Benchmarks Ideally your normal pages should

take

•  1 ~ 1.5 sec

•  40 ~ 60 mb of memory

•  100~300 queries per page

Simpler pages like 404 are good indicators of what is the fastest all other pages will run.


Profiling tools Chasing it

•  Use Devel module (http://drupal.org/project/devel ) to have a fast indication of page load times and memory consumption.

•  Use XhProf Module to profile the page and understand slower components.

•  Use timer_start(), timer_read() functions in situations where you are unsure.


Typical #1 – Slow queries •  First look to profiling data shows something really slow.

Problem •  Related to the database (Wall time vs Total Time). •  Number of queries is low, so probably it’s a single query. Solution •  Reduce query time in views ; Use Views Lite Pager

Devel XhProf


Problem •  High number of queries •  High memory consumption •  High number of function calls •  All those little queries and memory consumption mean that

you are loading lots of information from the database. Solution •  Look to XhProf and identify the root cause of all the excessive

function calls.

Devel XhProf

Typical #2 – Extra complexity


Typical #3 – Edge cases •  Slow functions only detectable by XhProf

• Eg: When problem is in PHP execution • Problematic if using popular hooks (hook_init,

hook_node_load). •  Infrastructure not being properly used

•  Requests bypassing Varnish •  Not enough APC memory

•  Blocks rendered in all pages and content hidden at template level.

•  Theme_rebuild and cache_clear_all in middle of code.


Typical #4 – Special tasks •  Usually a task executed in special situations or in

certain pages that seriously slows down the platform. •  Synchronizations of thousand of nodes from web

services. •  Synchronization of all user base from LDAP. •  Sending thousand of mails via Cron.

•  Even worst when those tasks are called by normal

page views.


Hands On Time


1.  Enable Devel

> Admin / Config / Devel -> Display query log, Display

page timer, Display memory usage

1.  Enable XhProf

> Admin / Config / XHProf

1.  Enable a browser inspector tool (Google Chrome

Developer tools or Firebug or etc..)

Exercise 1 - Enable tools


1. Go to Drupalistas tab

2.  Click on Demo user and Drupal commits

Exercise 2 - Slow Query


1. Go to Drupalistas tab

2.  Click on Demo user and Drupal commits

3.  Look to devel query log.

4. Go to user / uid 1 and see the difference

Exercise 2 - Slow Query


1. Go to a 404 page ( /prague)

2.  Look to XhProf report

Exercise 3 - Missed blocks




3.  Find the missing blocks (weather)

4.  FIx it by giving the right path





3.  Find the missing blocks (weather)

4.  Fix it by giving the right path



- Go to the sessions tab.

- Look to XhProf and Devel.

- Look to amount of memory and CPU.

Exercise 4 - Complexity


- Go to the sessions page.

- Look to XhProf and Devel.

- Look to amount of memory and CPU.

- Look to code to understand the amount of node_loads.

- Disable custom block and enable views block.

- Enable block cache alter

- Check difference

Exercise 4 - Complexity


- Go to a Drupalcon node

- Refresh a few times the page. Look to headers.

- Look to all requests done by the page.

Exercise 5 - Problems in infrastructure


- Go to a Drupalcon node

- Refresh a few times the page. Look to headers.

- Look to all requests done by the page.

- Identify missing header in the ajax Call done to get

attendance

- Look to code

Exercise 5 - Problems in infrastructure


1. Reduce complexity. Make sure your site is as slim as possible.

2. Cache where you can. At all levels.

3. Maintain cache as long as possible as long it is acceptable.

4. Compute behind the scenes when you can.

5. Distribute the heavier tasks to larger intervals.

6. Grow infrastructure if you are reaching server limits.

After you identified the problems

Caching after optimizing


Performance Can it be cached? Cache it!

•  Page caching, block caching, panels caching, views caching, caching API..

•  Review caching strategy:

•  https://www.acquia.com/blog/when-and-how-caching-can-save-your-site-part-2-authenticated-users

•  Guarantee that caching is effectively helping you.

•  Don’t clear it too often.

•  Not used only by a minority.


Summary ●  Make sure to look for others suffering from the same

problem.

●  Never hesitate to ask the most basic questions.

●  Go step by step, exclude possibilities if uncertain.

●  Learn the tools we introduced you to.

●  Always try to understand the whole system, not just the part throwing the error.


So, before your questions. I do have a question.

Would you like to join Acquia?

We are hiring EVERYWHERE in Europe! •  Consultants •  Support •  Sales •  Engineering


Thank you for your attention. Now question time!

THANK YOU!

WHAT DID YOU THINK?

Locate this session at the DrupalCon Prague website: http://prague2013.drupal.org/schedule

Click the “Take the survey” link

Fix me if you can - DrupalCon prague

Technology

Transcript of Fix me if you can - DrupalCon prague