@@ -6,9 +6,9 @@ title: Swig505 Notes » Web Application Security Web Application Security Checklist ---------------------------------- -### Cross-site Scripting +### Cross-site Scripting (XSS) -Is all user input sanitized before entering the database? Are user-defined values escaped on output? +Is all user input sanitized before entering the database? Are user-defined values escaped on output? Also, watch out for reflected XSS where a user parameter is directly output in the view (even if it never gets stored anywhere -- for example, a search term). * Escape output in views with html_escape (h) * Use Erubis or another auto-escaping alternative for rendering views @@ -40,4 +40,42 @@ And our controller could be setup the following way: @user = User.create(params[:user]) ... -A malevolent user can add any other parameters he/she wants to the request and our **User.create** code will call **<param>=** for each of those parameters. This means a user can easily change foreign keys, etc -- in fact, they can call any method that ends in an equals sign and takes one argument. Fortunately, Rails gives us a very simple mechanism for protecting these values: you can use attr\_protected or attr\_accessible in your models to disallow mass-assignment for particular attributes. Personally, I recommend always using attr\_accessible over attr\_protected since it follows the principle of _implicityly disallowing everything that isn't explicitly allowed_. +A malevolent user can add any other parameters he/she wants to the request and our **User.create** code will call **<param>=** for each of those parameters. This means a user can easily change foreign keys, etc -- in fact, they can call any method that ends in an equals sign and takes one argument. Fortunately, Rails gives us a very simple mechanism for protecting these values: you can use attr\_protected or attr\_accessible in your models to disallow mass-assignment for particular attributes. Personally, I recommend always using attr\_accessible over attr\_protected since it follows the principle of _implicitly disallowing everything that isn't explicitly allowed_. + + +### Cross-site Request Forgery (CSRF) + +Use a token to ensure that all forms (and any non-GET requests) are coming from the site rather than an external request. Rails 2+ gives you this functionality by default. + + +### HTTPS/SSL + +Not much to say here. Use SSL! With the power of processors ever-increasing and the cost ever-decreasing, there's not much of an excuse for not using SSL everywhere on your site. After all, scaling at the load balancer level really isn't that hard anyway. + + +### Cookies + +Use http-only on your cookies everywhere possible. If a user finds an XSS hole on the site, it gives you one more layer of protection against session hijacking. + + +### Authenticated Sessions / Login + +A few easy things to mitigate session hijacking: + +- Destroy session on login and logout (generating a new session id) +- Temporarily lock accounts that have multiple failed login attempts to prevent brute force attacks +- Require strong passwords (8 characters+, at least one letter and one number) + + +### Logging + +Ensure that sensitive data is filtered out before being logged. This includes credit card info, passwords, etc. + + +### Data Enumeration + +Is there an easy way for a user to determine whether a particular username exists in the system? Any other sensitive data that would be easy to enumerate. Naturally, this only matters in certain situations, so there are no hard and fast rules here. Sample targets include: + +- Does forget password give a different message if a username/email does or doesn't exist? +- Is the message on a failed login different if the username/password doesn't exist? + notes/development/web_application_security.markdown 02d43d578461f7827a274ea424d2d9f1dcf6b360 Brian Smith bsmith@swig505.com http://github.com/Lytol/swig505.com/commit/84329b9a29430909ca3063cf6e813092372486e5 84329b9a29430909ca3063cf6e813092372486e5 2009-07-02T17:13:50-07:00 2009-07-02T17:13:50-07:00 Added CSRF and the obvious others in security checklist 4eda3b7cbc6d6226178cf3876534ee97a13f4e33 Brian Smith bsmith@swig505.com