Drupal Security for Coders and Themers - XSS and CSRF

2,713 views
2,649 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,713
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Maybe you don't know it, but it is.
  • I'm pretty awesome.
  • It's pretty awesome.
  • Damn, they're really awesome.
  • Your site has some vulnerabilities in it somewhere – given enough time/effort someone could break in.
  • DO NOT LIKE Resources: * DDOS * Mail forwarding for spam * Bot network Stealing data * E-mails * Username/passwords * Worse? (credit card, ssn, etc.) Altering data * Homepage defacement * Changing prices in e-commerce * Deleting content http://www.flickr.com/photos/piez/995290158/
  • Being educated about security lets you know what to worry about. http://www.flickr.com/photos/filipamachado/3249193904/
  • XSS is the worst! Only for vulnerabilities fixed from d.o security team process, but anecdotally we know XSS is the worst! What about real world? Most people don't want to report their weaknesses.
  • XSS is the worst! Only for vulnerabilities fixed from d.o security team process, but anecdotally we know XSS is the worst! What about real world? Most people don't want to report their weaknesses.
  • For the Irving Berlin fans out there Javascript can do everything that you can do on the site. If you are logged in as an admin user, it can edit any users password, change permissions, etc.
  • 2. Demonstrate weak code. XSS is from “user input” - ALL user input! Including browser user agent! ### SETUP NOTES: 1. Install browscap and monitor user agents 2. Setup firefox useragent switcher with a useragent like <script>$("body").replaceWith("<h1>now what</h1>?");</script>
  • tpl.php and default theme_* implementations will show where to use check_plain etc. Good developers should know when/where/how to filter text, let them worry about it and hand you simple variables via preprocess functions.
  • Whenever you deal with assembling bits of text for output consider these three questions. Answers will determine whether any filtering is required. User agent in http request to include a file?
  • Data comes in from 'you' (or a malicious user) Goes to MySQL in some queries, MySQL returns data Data is returned to you What are the “Contexts” in this page request flow? MySQL context in step 2 Your browser in step 4
  • Steven Wittens wrote this up way better than anyone else. If you don't have an hour and don't have a themer or developer...use the cheat sheet
  • You deal with a string Input comes in, any yes answer drops down, HTML output at the bottom. Sometimes we use the underlying function like check_url via a convenience function like l(). Ditto check_plain via t(). Rich text may contain html, may contain Wiki formatting. Trusted text is way less than 1% of the text on a site.
  • 3 rd most common, 2 nd hardest to “solve”
  • User Protect module http://drupal.org/node/623162 Enable Go to admin/user/userprotect View Delete problem Create a node with <img src=” http://6d.local/userprotect/delete/1/user “> or a tinyurl or...or be sure to fix the “smart quotes” Refresh admin/user/userprotect – no longer protected!
  • Drupal Security for Coders and Themers - XSS and CSRF

    1. 1. Your site is vulnerable. (really, it is)
    2. 2. I want you: To see the vulnerabilities
    3. 3. Disney Princess Castle!
    4. 6. <ul><li>Drupaler for 4 years
    5. 7. Drupal Association
    6. 8. Help with lots of d.o
    7. 9. 20+ modules (Pathauto, token)
    8. 10. On Security Team
    9. 11. MasteringDrupal.com
    10. 12. DrupalDashboard.com
    11. 13. @knaddison </li></ul>Greg
    12. 14. <ul>&quot;Cracking Drupal is probably going to be the first Drupal book I buy.&quot; - Angie 'webchick' Byron </ul>Wrote a book Or 40% off with Wiley coupon.
    13. 15. GVS <ul><li>Development
    14. 16. Community focused
    15. 17. Progressive
    16. 18. Event management
    17. 19. Now....
    18. 20. Security
    19. 21. (with Ben) -> </li></ul>
    20. 22. Worry
    21. 23. Your site is vulnerable. You can make it safer.
    22. 24. “ A site is secure if private data is kept private, the site cannot be forced offline or into a degraded mode by a remote visitor, the site resources are used only for their intended purposes, and the site content can be edited only by appropriate users.” Some guy – Cracking Drupal chapter 1
    23. 25. <ul><li>Abusing resources
    24. 26. Stealing data
    25. 27. Altering data </li></ul>
    26. 28. Worry in a prioritized way.
    27. 30. http://www.cenzic.com/downloads/Cenzic_AppSecTrends_Q1-Q2-2009.pdf
    28. 31. Anything you can do XSS can do (better) 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(/id=&quot;edit-user-profile-form-form-token&quot; value=&quot;([a-z0-9])&quot;/); var token = matches[1]; // Post the minimum amount of fields. Other fields get their default values. var payload = { &quot;form_id&quot;: 'user_profile_form', &quot;form_token&quot;: token, &quot;pass[pass1]&quot;: 'hacked', &quot;pass[pass2]&quot;: 'hacked' }; jQuery.post(Drupal.settings.basePath + 'user/1/edit', payload); } } ); } http://crackingdrupal.com/node/8
    29. 32. demo time
    30. 33. Tests for XSS <ul><script>alert('xss');</script> <img src=”notfound.png” onerror=”alert('xss');”> </ul>
    31. 34. Themers <ul><li>Read tpl.php and default implementations
    32. 35. Rely on your module developer for variables
    33. 36. Run the tests </li></ul>
    34. 37. Developers Where does this text come from? Is there a way a user can change it? In what context is it being used?
    35. 39. Context <ul><li>Mail context
    36. 40. Database context
    37. 41. Web context
    38. 42. Server context </li></ul>Take an hour: http://acko.net/blog/safe-string-theory-for-the-web
    39. 44. Cross Site Request Forgery <ul><li>Taking action
    40. 45. Without confirming intent
    41. 46. AKA CSRF </li></ul>
    42. 47. Cross Site Request Forgery <ul>Demo time </ul>
    43. 48. Solutions to CSRF <ul><li>Create a token based on something unique to </li><ul><li>site, the user, and the action and
    44. 49. validate the token when the action is requested </li></ul><li>Request: </li><ul><li>'query' = array('token' => drupal_get_token('my_id'); </li></ul><li>Processing: </li><ul><li>if (!drupal_valid_token($_GET['token'], 'my_id')) { </li></ul></ul><ul>(Or just use the Form API) </ul>
    45. 50. Security and Usability <ul><li>Confirmation forms == teh suck
    46. 51. Truly destructive actions should be hard to do
    47. 52. Don't delete, archive and provide undo
    48. 53. Choose links or forms for usability, not security </li></ul>
    49. 54. Severities and Other Vulnerabilities <ul><li>drupal.org/security/contrib lots of other categories of vulnerabilities in addition to XSS and CSRF
    50. 55. drupal.org/security-team </li></ul>
    51. 56. New Resource... <ul><li>http://DrupalSecurityReport.org </li></ul>Ustima.com
    52. 57. Resources <ul><li>http://drupal.org/security-team
    53. 58. http://drupal.org/security
    54. 59. http://drupal.org/writing-secure-code
    55. 60. http://groups.drupal.org/node/15254 - discussion group
    56. 61. http://heine.familiedeelstra.com/
    57. 62. Cracking Drupal - http://crackingdrupal.com
    58. 63. http://crackingdrupal.com/node/34 - XSS Cheat Sheet
    59. 64. http://crackingdrupal.com/node/48 - CSRF
    60. 65. http://www.drupalsecurityreport.org </li></ul>

    ×