Web app security checklist (Braindump)

John McCaffrey, Thursday, May 14, 2009 @ 3:21 pm

In Yesterday's post I said I'd put together a quick list of things to think about around web application security. This is by no means an exhaustive list, but its a set of categories and things I start to look at when doing a security assessment on an app.

Web Application Security Checklist
Account management

• Password management (validation, expiration, previous passwords, etc)
• Account lockout (number of tries, IP auditing, etc)
• Role management

Data management

• Don't Leak sensitive user info (SSNs, account numbers, other identity info) in URLs, cookies, sessions, logs, or printable pages.
• User Auditing (who changed what, and when)

Browser hacks

• Cross Site Scripting (XSS)
• Cross Site Request Forgery (XSRF)

Encrypted transport (make sure Ajax calls are secure)
Encrypted storage (credit cards, ssns, etc)
Server configuration (firewalls, web/app server, db)

I actually have a longer list, but its not formatted/organized very well,  so this is my first cut at sharing it with others.

What other areas do you look at when doing security checks for your web apps?

What tools do you use?

Related posts:

1. The Truth About Designing For Security
2. Avoid the last minute security review
3. GWT Security Talk
4. Ajax security surprises: web-aggregators, offline applications and frameworks
5. Google Gears Security Thoughts

Comments (5)

Software Development

Comments: 5 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. [...] I’ll post a quick checklist of general areas to look into for web application [...]

   Pingback by Agile Ajax » Avoid the last minute security review » Pathfinder Development, Thursday, May 14, 2009 @ 3:22 pm

2. 

   Sometimes it’s the obvious things. Be on the lookout for possible SQL injection vectors. Rails makes this easy for all the most common cases, but that ease can be an opiate when it comes to special cases, such as using find_by_sql where you have to be responsible for parameter scrubbing yourself (using ActiveRecord::Base.sanitize_sql_array, et al). For the same reason take care when inserting parameters into a find rder option, which I believe just inserts the provided string directly into the SQL.

   Comment by Chris Vincent, Thursday, May 14, 2009 @ 4:16 pm

3. 

   Good list but obvious. Something profound and unheard would be helpful.

   Comment by A to Z of the World, Friday, May 15, 2009 @ 1:41 am

4. 

   Have you seen the find_mass_assignment plugin by the guys at Insoshi? Handy for finding potential holes;

   http://github.com/jamis/safe_mass_assignment/tree/master
   http://blog.mhartl.com/2008/09/21/finding-and-fixing-mass-assignment-problems-in-rails-applications/

   A few weeks back I printed out the rails_security_2.pdf from the rorsecurity guys and put it on the kitchen table for breakfast reading. I’m sure they’ve covered the main gotchas
   http://www.owasp.org/index.php/Image:Owasp-rails-security.pdf

   Comment by Neil, Friday, May 15, 2009 @ 9:58 am

5. 

   Phishing holes. Especially in public help sections, some of which are set up by tech writers and tend to use framesets. Often something which gets quickly added at the end when the product goes live.

   Comment by Halans, Sunday, May 17, 2009 @ 7:23 pm

Leave a comment