Ruby on Rails Security

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.

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 ﬂush 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

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

24.
XSS - HTML Filtering
Utilize Tidy if you want to be more cautious
24

25.
Session Fixation
Provide the user with a session that he shares with the attacker:
25

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

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

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.
JavaScript Hijacking
http://my.evil.site/
JSON response
The JSON response will be evaled by the Browser’s JavaScript engine.
With a redeﬁned `Array()` function this data can be sent back to http://my.evil.site
32

33.
JavaScript Hijacking Prevention
• Don’t put important data in JSON responses
• Use unguessable URLs
• Use a Browser that does not support the redeﬁnition of Array & co,
currently only FireFox 3.0
• Don’t return a straight JSON response, preﬁx it with garbage:
The Rails JavaScript helpers don’t support preﬁxed JSON responses
33

35.
Mass Assignment
Handling in Controller
A malicious user could just submit any value he wants
35

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

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 trafﬁc 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

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