Ruby on Rails Security
- 1. Ruby on Rails Security
Jonathan Weiss, 30.12.2007
Peritor Wissensmanagement GmbH
- 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. 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
- 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. 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. 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. 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. 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. 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. 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
- 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. 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. 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. 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. XSS - Custom Tags
Relying on the external syntax is not really secure
Filter HTML anyhow
21
- 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. XSS - HTML Filtering
sanitize(html, options = {})
http://api.rubyonrails.com/classes/ActionView/Helpers/SanitizeHelper.html
23
- 24. XSS - HTML Filtering
Utilize Tidy if you want to be more cautious
24
- 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. 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. 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. 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
- 31. SQL Injection Protection in Rails
Always use the escaped form
If you have to manually use a user-submitted value, use `quote()`
31
- 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
- 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. 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. 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. 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. 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. 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
- 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. 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