Page 0: Page 1: Ruby on Rails Security Jonathan Weiss, 30.12.2007 Peritor Wissensmanagement GmbH Page 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 Page 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 Page 4: Rails Application Setup 4 Page 5: Rails Setup 5 Page 6: Rails Setup - FastCGI 6 Page 7: Rails Setup - Mongrel 7 Page 8: Information leaks and possible vulnerabilities 8 Page 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 Page 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 Page 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 Page 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 Page 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 2006-04-14T03:06:39.902218Z 34 justin@joyent.com … Prevent .svn download <DirectoryMatch "^/.*/\.svn/"> ErrorDocument 403 /404.html Order allow,deny Deny from all Satisfy All </DirectoryMatch> 13 Page 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 Page 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 Page 16: Cookie Session Storage Rails default session secret Set HTTPS only cookies 16 Page 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 Page 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 Page 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 Page 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 Page 21: XSS - Custom Tags Relying on the external syntax is not really secure Filter HTML anyhow 21 Page 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 Page 23: XSS - HTML Filtering sanitize(html, options = {}) http://api.rubyonrails.com/classes/ActionView/Helpers/SanitizeHelper.html 23 Page 24: XSS - HTML Filtering Utilize Tidy if you want to be more cautious 24 Page 25: Session Fixation Provide the user with a session that he shares with the attacker: 25 Page 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 Page 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 Page 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 Page 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 Page 30: SQL Injection The users input is not correctly escaped before using it in SQL statements 30 Page 31: SQL Injection Protection in Rails Always use the escaped form If you have to manually use a user-submitted value, use `quote()` 31 Page 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 Page 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 Page 34: Mass Assignment User model 34 Page 35: Mass Assignment Handling in Controller A malicious user could just submit any value he wants 35 Page 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 Page 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 Page 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 Page 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 Page 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 Page 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 Page 42: Conclusion 42 Page 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 Page 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 Page 45: