Secure Application Development and the OWASP Top 10 (Pt. 3 of 10)
This is part 3 of a 10-part series. Be sure to check out part 1 and part 2 if you haven’t already.
Some of you may already be familiar with the Open Web Application Security Project (OWASP) and its Top 10 2010 list due in part to Requirement 6.5 of the Payment Card Industry Data Security Standard (PCI DSS):
6.5 Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities in software development processes.
For those of you who are not familiar with OWASP and their Top 10, the OWASP Top 10 2010 was aimed at highlighting simple problems that can plague applications and ultimately undermine security.
If you missed it, be sure to check out the previous posts on A1: Injection and A2: Cross-Site Scripting (XSS). Here’s the third OWASP application security risk - Broken Authentication and Session Management.
A3: Broken Authentication and Session Management
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.
Avoiding broken authentication and session management is essentially all about trying to protect your credentials and session IDs. Let’s take a look at each of those items separately.
Credentials
Credentials are typically made up of usernames and passwords. It should come as no surprise that they should be protected inside of web applications.
When storing passwords, it is strongly recommended that they be hashed and salted.
- Hashing is a one-way cryptographic function that is meant to make decryption computationally infeasible. The most common hashing algorithms are MD5 and SHA-1.
- Salting is the process of adding a value to each password so that two users with the same password have different final hash values.
The technique of using a “salted hash” thwarts the use of a rainbow table attack and slows down other types of offline password cracking attacks.
Here are some tips for handling credentials:
- Do not store usernames and/or passwords in cookies.
- Do not pre-populate password fields for “Change Password” or “Remember Me” functions (you should be hashing the password anyway).
- Lockout user accounts after a reasonable number of failed attempts.
- Issue the same error message for a non-existent user and incorrect password to prevent username enumeration.
- Always use POST instead of GET to transmit credentials.
- Disable autocomplete on forms with password fields to prevent browser caching.
Session IDs
HTTP (the protocol that powers the web) is a stateless protocol. That means that the original protocol specification has no way to track a user across multiple web requests.
So how do web applications keep track of you across multiple requests? Session IDs.
Session IDs are typically stored in cookies. Every time you request a web resource, any relevant cookies are sent along with that request. In the case of session ID cookies, if you have logged into a site, these cookies are then mapped on the server-side to your authenticated session. If you want to view these cookie interactions, The Live HTTP headers Firefox add-on is a quick way to see this exchange of cookies.
So what’s the big deal?
Well, if an attacker steals your session cookie, he or she won’t need your password to access your account.
The best real world example of this is Firesheep. Firesheep is designed to steal these session ID cookies and reuse them to impersonate the victim on popular websites like Facebook, Twitter and Google (all the more reason to always log out of websites when you’re done using them, helping to thwart session-based attacks).
Here are some tips for handling session IDs:
- Do not include session IDs in URLs.
- Issue a new session ID upon successful authentication to prevent session fixation.
- Invalidate session IDs when users log out.
- Set up the application to time out session IDs.
Up next in the series, I will be looking at A4: Insecure Direct Object References.
Zach Grace submitted this to 