Download as PDF, PPTX
Uploaded byPhong Nguyễn Đình
Ruby on-rails-security
Jonathan Weiss presented on Ruby on Rails security. He discussed potential vulnerabilities in Rails application setup and deployment, application code, and the Rails framework. He highlighted information leaks, SQL injection, cross-site scripting (XSS), session fixation, cross-site request forgery (CSRF), mass assignment, and denial of service attacks as specific security risks and provided best practices for mitigating each one.
Ruby on-rails-security
- 1. Ruby on RailsSecurity 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
- 4.
- 5.
- 6. Rails Setup -FastCGI 6
- 7. Rails Setup -Mongrel 7
- 8. Information leaks and possible vulnerabilities 8
- 9. Information leaks Is thetarget 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 thetarget 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 "^/.*/.svn/"> 34 ErrorDocument 403 /404.html justin@joyent.com Order allow,deny … Deny from all Satisfy All </DirectoryMatch> 13
- 14. Cookie Session Storage SinceRails 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 Securityimplications • 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. Cookie Session Storage Railsdefault session secret Set HTTPS only cookies 16
- 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 - NoFormatting 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 - FormattingAllowed 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 - CustomTags Relying on the external syntax is not really secure Filter HTML anyhow 21
- 22. XSS - HTMLFiltering 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 - HTMLFiltering sanitize(html, options = {}) http://api.rubyonrails.com/classes/ActionView/Helpers/SanitizeHelper.html 23
- 24. XSS - HTMLFiltering Utilize Tidy if you want to be more cautious 24
- 25. Session Fixation Provide theuser with a session that he shares with the attacker: 25
- 26. Session Fixation Rails usesonly 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 inRails 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 inRails 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 usersinput is not correctly escaped before using it in SQL statements 30
- 31. SQL Injection Protectionin 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/ JSONresponse 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. 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.
- 35. Mass Assignment Handling inController 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 codethrough 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 tohandle 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 ofService 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 ofService 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 RequestDoS 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. Conclusion 42
- 43. Conclusion Rails hasmany 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ße2 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