0
Ruby on Rails Security




Jonathan Weiss, 30.12.2007
Peritor Wissensmanagement GmbH
Who am I ?

Jonathan Weiss

• Consultant for Peritor Wissensmanagement GmbH
• Specialized in Rails, Scaling, and Code Revi...
Agenda



                              Follow the application stack
                              and look for
 Setup and...
Rails Application Setup




                          4
Rails Setup




              5
Rails Setup - FastCGI




                        6
Rails Setup - Mongrel




                        7
Information leaks
          and
possible vulnerabilities




                           8
Information leaks

Is the target application a Rails application?
 • Default setup for static files:
     /javascripts/appl...
Information leaks

Is the target application a Rails application?
 • Rails provides default templates for 404 and 500 stat...
Sample Status Pages
 http://www.twitter.com/500.html      http://www.43people.com/500.html




http://www.strongspace.com/...
Server Header

GET http://www.43people.com

Date: Tue, 25 Dec 2007 21:23:24 GMT
Server: Apache/1.3.34 (Unix) mod_deflate/1...
Information leaks

Subversion metadata
  • Typically Rails applications are deployed with Capistrano / Webistrano
  • This...
Cookie Session Storage

Since Rails 2.0 by default the session data is stored in the cookie




Base64(CGI::escape(SESSION...
Cookie Session Storage

Security implications
 • The user can view the session data in plain text
 • The HMAC can be brute...
Cookie Session Storage

Rails default session secret




Set HTTPS only cookies




                               16
Cross-Site Scripting - XSS



“The injection of HTML or client-side Scripts (e.g. JavaScript) by malicious users into
web ...
Cross-Site Scripting - XSS


Cases of accepted user input
 • No formatting allowed
    search query, user name, post title...
XSS - No Formatting Allowed

Use the Rails `h()` helper to HTML escape user input




But using `h()` everywhere is easy t...
XSS - Formatting Allowed

Two approaches


 Use custom tags that will translate to HTML (vBulletin tags, RedCloth, Textile...
XSS - Custom Tags

Relying on the external syntax is not really secure




              Filter HTML anyhow




          ...
XSS - HTML Filtering

Use the Rails `sanitize()` helper




Only effective with Rails 2.0:
  • Filters HTML nodes and attr...
XSS - HTML Filtering

sanitize(html, options = {})




http://api.rubyonrails.com/classes/ActionView/Helpers/SanitizeHelpe...
XSS - HTML Filtering

Utilize Tidy if you want to be more cautious




                                               24
Session Fixation



Provide the user with a session that he shares with the attacker:




                                ...
Session Fixation

Rails uses only cookie-based sessions


Still, you should reset the session after a login




The popula...
Cross-Site Request Forgery - CSRF



You visit a malicious site which has an image like this




Only accepting POST does ...
CSRF Protection in Rails



By default Rails 2.0 will check all POST requests for a session token




All forms generated ...
CSRF Protection in Rails


Very useful and on-by-default, but make sure that
 • GET requests are safe and idempotent
 • Se...
SQL Injection


The users input is not correctly escaped before using it in SQL statements




                           ...
SQL Injection Protection in Rails


Always use the escaped form




If you have to manually use a user-submitted value, us...
JavaScript Hijacking

http://my.evil.site/




 JSON response




The JSON response will be evaled by the Browser’s JavaSc...
JavaScript Hijacking Prevention

 • Don’t put important data in JSON responses
 • Use unguessable URLs
 • Use a Browser th...
Mass Assignment

User model




                  34
Mass Assignment

Handling in Controller




A malicious user could just submit any value he wants




                    ...
Mass Assignment

Use `attr_protected` and `attr_accessible`




                       Vs.




Start with `attr_protected`...
Rails Plugins

Re-using code through plugins is very popular in Rails


Plugins can have their problems too
 • Just becaus...
Rails Plugins

How to handle plugins
 • Always do a code review of new plugins and look for obvious problems
 • Track plug...
Rails Denial of Service Attacks

Rails is single-threaded and a typical setup concludes:
 • Limited number of Rails instan...
Rails Denial of Service Attacks

A denial of service attack is very easy if Rails is handling down/uploads.
Just start X (...
Rails Slow Request DoS Prevention

 Serve static files directly through the web server
    • Apache, Lighttpd, nginx (use x...
Conclusion




             42
Conclusion


 Rails has many security features enabled by default
    • SQL quoting
    • HTML sanitization
    • CSRF pro...
Peritor Wissensmanagement GmbH
Lenbachstraße 2
12157 Berlin
Telefon: +49 (0)30 69 40 11 94
Telefax: +49 (0)30 69 40 11 95
...
Upcoming SlideShare
Loading in...5
×

Ruby on Rails Security

47,416

Published on

The slides from the 24C3 session "Ruby on Rails Security" by Jonathan Weiss, 30.12.2007.

Even though Ruby on Rails introduces a lot of best practices to the developer, it is still quite easy for an imprudent programmer to forget that every web application is a potential target. Web application attacks like Cross Site Scripting or Cross Site Request Forgery are very popular these days and every Rails developer should have an idea about the different possibilities that his application presents to an attacker.

This talk will cover most of the common web application vulnerabilities like Cross Site Scripting and Cross Site Request Forgery, SQL and Code injection, and deployment security and how they apply to Rails. Further Ruby on Rails specific issues like Rails plugin security, JavaScript/Ajax security, and Rails configuration will be examined and best practices introduced.

Published in: Technology
8 Comments
91 Likes
Statistics
Notes
  • What a great slide! We're looking at message broker solutions right now ... you a top candidate!
    http://www.mediafire.com/download/kx9l74xfsn96454/
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • It is quite interesting and fu
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • clear information.thanks for your slide share.
    hope will get more slides from you!!http://scambaitings.blogspot.com/
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Very very interesting and usefull!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • excellent
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
47,416
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
1,721
Comments
8
Likes
91
Embeds 0
No embeds

No notes for slide

Transcript of "Ruby on Rails Security"

  1. 1. Ruby on Rails Security Jonathan Weiss, 30.12.2007 Peritor Wissensmanagement GmbH
  2. 2. Who am I ? Jonathan Weiss • Consultant for Peritor Wissensmanagement GmbH • Specialized in Rails, Scaling, and Code Review • Active member of the Rails community • MeinProf.de - one of the first big German Rails sites • Webistrano - Rails deployment tool • FreeBSD Rubygems and Ruby on Rails maintainer 2
  3. 3. Agenda Follow the application stack and look for Setup and deployment • Information leaks Application code • Possible vulnerabilities • Best practices Framework code Rails Application Stack 3 3
  4. 4. Rails Application Setup 4
  5. 5. Rails Setup 5
  6. 6. Rails Setup - FastCGI 6
  7. 7. Rails Setup - Mongrel 7
  8. 8. Information leaks and possible vulnerabilities 8
  9. 9. Information leaks Is the target application a Rails application? • Default setup for static files: /javascripts/application.js /stylesheets/application.css /images/foo.png • Pretty URLs /project/show/12 /message/create /folder/delete/43 /users/83 9
  10. 10. Information leaks Is the target application a Rails application? • Rails provides default templates for 404 and 500 status pages • Different Rails versions use different default pages • 422.html only present in applications generated with Rails 2.0 10
  11. 11. Sample Status Pages http://www.twitter.com/500.html http://www.43people.com/500.html http://www.strongspace.com/500.html Rails >= 1.2 status 500 page 11
  12. 12. Server Header GET http://www.43people.com Date: Tue, 25 Dec 2007 21:23:24 GMT Server: Apache/1.3.34 (Unix) mod_deflate/1.0.21 mod_fastcgi/2.4.2 mod_ssl/2.8.25 OpenSSL/0.9.7e-p1 Cache-Control: no-cache … GET https://signup.37signals.com/highrise/solo/signup/new Date: Tue, 25 Dec 2007 21:23:24 GMT Server: Mongrel 1.1.1Status: 200 OK … Disable Server header # httpd.conf Header unset Server 12
  13. 13. Information leaks Subversion metadata • Typically Rails applications are deployed with Capistrano / Webistrano • This will push .svn directories to the servers GET http://www.strongspace.com/.svn/entries … dir 25376 http://svn.joyent.com/joyent/deprecated_repositories/www.strongspace/trunk/public http://svn.joyent.com/joyent Prevent .svn download 2006-04-14T03:06:39.902218Z <DirectoryMatch quot;^/.*/.svn/quot;> 34 ErrorDocument 403 /404.html Order allow,deny justin@joyent.com Deny from all … Satisfy All </DirectoryMatch> 13
  14. 14. Cookie Session Storage Since Rails 2.0 by default the session data is stored in the cookie Base64(CGI::escape(SESSION-DATA))--HMAC(secret_key, SESSION-DATA) 14
  15. 15. Cookie Session Storage Security implications • The user can view the session data in plain text • The HMAC can be brute-forced and arbitrary session data could be created • Replay attacks are easier as you cannot flush the client-side session Countermeasures • Don’t store important data in the session! • Use a strong password, Rails already forces at least 30 characters • Invalidate sessions after certain time on the server side … or just switch to another session storage 15
  16. 16. Cookie Session Storage Rails default session secret Set HTTPS only cookies 16
  17. 17. Cross-Site Scripting - XSS “The injection of HTML or client-side Scripts (e.g. JavaScript) by malicious users into web pages viewed by other users.” 17
  18. 18. Cross-Site Scripting - XSS Cases of accepted user input • No formatting allowed search query, user name, post title, … • Formatting allowed post body, wiki page, … 18
  19. 19. XSS - No Formatting Allowed Use the Rails `h()` helper to HTML escape user input But using `h()` everywhere is easy to forget • Use safeERB plugin • safeERB will raise an exception whenever a tainted string is not escaped • Explicitly untaint string in order to not escape it http://agilewebdevelopment.com/plugins/safe_erb 19
  20. 20. XSS - Formatting Allowed Two approaches Use custom tags that will translate to HTML (vBulletin tags, RedCloth, Textile, …) Use HTML and remove unwanted tags and attributes • Blacklist - Rails 1.2 • Whitelist - Rails 2.0 20
  21. 21. XSS - Custom Tags Relying on the external syntax is not really secure Filter HTML anyhow 21
  22. 22. XSS - HTML Filtering Use the Rails `sanitize()` helper Only effective with Rails 2.0: • Filters HTML nodes and attributes • Removes protocols like “javascript:” • Handles unicode/ascii/hex hacks 22
  23. 23. XSS - HTML Filtering sanitize(html, options = {}) http://api.rubyonrails.com/classes/ActionView/Helpers/SanitizeHelper.html 23
  24. 24. XSS - HTML Filtering Utilize Tidy if you want to be more cautious 24
  25. 25. Session Fixation Provide the user with a session that he shares with the attacker: 25
  26. 26. Session Fixation Rails uses only cookie-based sessions Still, you should reset the session after a login The popular authentication plugins like restful_authentication are not doing this! 26
  27. 27. Cross-Site Request Forgery - CSRF You visit a malicious site which has an image like this Only accepting POST does not really help 27
  28. 28. CSRF Protection in Rails By default Rails 2.0 will check all POST requests for a session token All forms generated by Rails will supply this token 28
  29. 29. CSRF Protection in Rails Very useful and on-by-default, but make sure that • GET requests are safe and idempotent • Session cookies are not persistent (expires-at) 29
  30. 30. SQL Injection The users input is not correctly escaped before using it in SQL statements 30
  31. 31. SQL Injection Protection in Rails Always use the escaped form If you have to manually use a user-submitted value, use `quote()` 31
  32. 32. JavaScript Hijacking http://my.evil.site/ JSON response The JSON response will be evaled by the Browser’s JavaScript engine. With a redefined `Array()` function this data can be sent back to http://my.evil.site 32
  33. 33. JavaScript Hijacking Prevention • Don’t put important data in JSON responses • Use unguessable URLs • Use a Browser that does not support the redefinition of Array & co, currently only FireFox 3.0 • Don’t return a straight JSON response, prefix it with garbage: The Rails JavaScript helpers don’t support prefixed JSON responses 33
  34. 34. Mass Assignment User model 34
  35. 35. Mass Assignment Handling in Controller A malicious user could just submit any value he wants 35
  36. 36. Mass Assignment Use `attr_protected` and `attr_accessible` Vs. Start with `attr_protected` and migrate to `attr_accessible` because of the different default policies for new attributes. 36
  37. 37. Rails Plugins Re-using code through plugins is very popular in Rails Plugins can have their problems too • Just because somebody wrote and published a plugin it doesn’t mean the plugin is proven to be mature, stable or secure • Popular plugins can also have security problems, e.g. restful_authentication • Don’t use svn:externals to track external plugins, if the plugin’s home page is unavailable you cannot deploy your site 37
  38. 38. Rails Plugins How to handle plugins • Always do a code review of new plugins and look for obvious problems • Track plugin announcements • Track external sources with Piston, a wrapper around svn:externals http://piston.rubyforge.org/ 38
  39. 39. Rails Denial of Service Attacks Rails is single-threaded and a typical setup concludes: • Limited number of Rails instances • ~8 per CPU • Even quite active sites (~500.000 PI/day ) use 10-20 CPUs • All traffic is handled by Rails 39
  40. 40. Rails Denial of Service Attacks A denial of service attack is very easy if Rails is handling down/uploads. Just start X (= Rails instances count) simultaneous down/uploads over a throttled line. This is valid for all slow requests, e.g. • Image processing • Report generation • Mass mailing 40
  41. 41. Rails Slow Request DoS Prevention Serve static files directly through the web server • Apache, Lighttpd, nginx (use x-sendfile for private files) • Amazon S3 Contaminate slow requests • Define several clusters for several tasks • Redirect depending on URL 41
  42. 42. Conclusion 42
  43. 43. Conclusion Rails has many security features enabled by default • SQL quoting • HTML sanitization • CSRF protection The setup can be tricky to get right Rails is by no means a “web app security silver bullet” but adding security is easy and not a pain like in many other frameworks 43
  44. 44. Peritor Wissensmanagement GmbH Lenbachstraße 2 12157 Berlin Telefon: +49 (0)30 69 40 11 94 Telefax: +49 (0)30 69 40 11 95 Internet: www.peritor.com E-Mail: kontakt@peritor.com 44 ©Peritor Wissensmanagement GmbH - Alle Rechte vorbehalten 44
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×