Top Five Ways Developers can Abuse Drupal

Drupal is a widely popular open source content management system (CMS). It’s powering big name sites, including WhiteHouse.gov, AOL Corporate, AT&T, CNN, Fast Company and so on. With such a wide following, it is easy for developers to abuse the platform in several ways. And they do.

Here are the top five ways Drupal is typically abused:

  1. 1.  XSS – Cross-Site Scripting
  2. 2.  Access Bypass
  3. 3.  CSRF
  4. 4.  SQL Injection
  5. 5.  Code execution

    One of the best practices when it comes to Drupal development is to use the Drupal API. Follow what core is doing. Most of the approaches Drupal’s API/core take are safe and recommended by the Drupal Security community. The Drupal API will prevent XSS by checking and sanitizing the values.

    As a Themer, you want to follow default implementations. Don’t place functions or scripts inside the template. Instead, rely on the module developers for supplying the variables. Typically if the module developers are following Drupal best practices, then you can assume that you are safe. The general idea is that the developers will be the key holders to the data severed.

    As a Developer, you have to ask yourself some major questions about the information you are working with.

    • Where does it originate from?
    • Is there a way the user can change it?
    • What context is it being used?

    Typically the process is as follows:

    User > Drupal > MySQL > Drupal > User

    A good rule of thumb as a Developer is to mimic how Core serves data. By following the Drupal Core practices, you will have stronger protection against the site being cracked.

    The context of how the data is served will determine the process you serve it back to the user.

    For more information visit:

    http://acko.net/blog/safe-string-theory-for-the-web

    http://drupal.org/node/16489

    Cross-site request forgery is the second most common problem in Drupal (taking actions without confirming intent, AKA CSRF). For instance, a user can be deleted via an URL by interjecting the server request in an image tag. To prevent such an injection, set the input format filter and use tokens for links. By setting the input format filter, you can control the user’s ability to create or call images, JavaScript, PHP, etc. The preferred practice is to not let the user create such things. By allowing users to create such elements you are jeopardizing your site for interjections. With a token added to the end of an URL, you can prevent an interjection by using drupal_get_token(‘myid’) and drupal_valid_token($GET[‘token’],’myid’). Another good practice is to always use Drupal’s Form API because it automatically uses tokens.

    The great thing about Drupal is it’s extremely large, and helpful community, which is constantly checking severalties and other vulnerabilities.

    Severalties and other vulnerabilities can be viewed here:

    http://drupal.org/security/contrib

    You will see a lot of other categories of vulnerabilities in addition to XSS and CSRF.

    You can also see what possible risks you might have by using certain modules at the following URL:

    http://drupal.org/security-team/risk-levels

    Author’s note: a good rule of thumb is if there is no fix, disable.

    The most typical ways your site is abused is by arbitrary code execution, SQL interjection, access bypassing and directory traversal.

    Arbitrary Code Execution

    This usually means some site user may be able to run PHP commands, or PHP in a file (a log file) may be included and executed. The most obvious, though sometimes overlooked, solution is allowing users to use the PHP input format. Recent examples include uses of preg_replace() where the result of the regular expression match could be executed as PHP.

    SQL Injection

    User input is added directly to the SQL that is sent to the database. In some cases this can allow users to delete or alter anything in the database (http://xkcd.com/327/). In other cases, it can reveal private information in the database – such as email addresses, hashed passwords, etc., which are used as the basis for further attack.

    Access Bypass

    This covers two problems: information disclosure and authentication bypass. Information disclosure: content is supposed to be protected, but isn’t. Authentication bypass: normal users can access an administrative page or operation.

    Directory Traversal

    The contents of a file chosen by the attacker can be included into the output. Typically this is when filenames are taken from the URL or other user input and characters links are not correctly escaped. This can reveal sensitive server information, your Drupal database credential, etc.

    Code execution possibility is the greatest danger.

    SQL injection + access bypass

    EX: BAD   = db_query_range(‘SELECT * FROM {node} n WHERE n.uid =’.arg(1), 0, 10);

    Good = db_query_range(‘db_rewrite_SQL(‘SELECT * FROM {node} n WHERE n.uid = %d AND published = 1’),  arg(1), 0, 10);

    Resources:

    http://drupalsecurityreport.org
    http://drupal.org/security
    http://drupal.org/security-team
    http://drupal.org/security/secure-configuration
    http://drupal.org/writing-secure-code
    http://heine.familiedeelstra.com
    http://crackingdrupal.com

    Advertisement

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )

    Connecting to %s