Download - 2009 Barcamp Nashville Web Security 101
Web Security 101
Who is this guy?
Brian Daileyrealm3 web applications
Security is serious.
Even when youmight think it's not.
TRUST MESecurity is all about trust.
PhysicalNetworkServerApplication
XSS
The user believes you are this guy:
But this guy isreally 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!
document.write('');
XSS
Another example:
Embed a form that captures a saved password, collect it.
If you can inject Javascript or HTML, you can do all sorts of nefarious things.
XSS
PreventionAlways Escape Output
How you escape depends upon context. URL Encoded
HTML Entities
White listing HTML tags (black listing is tricky!)
CSRF
(Cross-site Request Forgery)
Exploit server's trust of user.
CSRF
You think this isyour user:
But really it is:
CSRF
Example:
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
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"));
Frameworks are helpful.
They can come with their own set of issues.
Mass Assignment
Mass Assignment
Rails Example:@user = User.find(current_user.id)@user.update_attributes(params[:user])
If I POST user[is_admin] = 1W00t! 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);
Ownership
Ownership Authorization
Rails:# bad@post = Post.find(params[:id])# good@post = current_user.posts.find(params[:id])
Ownership Authorization
CakePHP:// bad$post = $this->Post->findById($id);// good$post = $this->Post->find(array('conditions' => array('id' => $id,'user_id' => $this->Auth->user('id'),));
Ownership Authorization
Symfony:// bad$post = Doctrine::getTable('Post')->find($id);// good $post = Doctrine_Query::create() ->select('*') ->from('Post p') ->where('p.id = ?', $id) ->where('p.user_id = ?', $user_id);
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 Securityhttp://code.google.com/edu/security/index.html
Rails Security Guidehttp://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 Daileyrealm3 web applications
Web: http://realm3.com/Twitter:@brian_daileyEmail:[email protected]/Phone: 917-512-3594
slide-bg: http://bit.ly/xc0m1Kudos to: http://asi9.net/