OWASP Top 10 2007 Update RC1 - A7 A8

A7 Broken Authentication and Session Management
Not really much I can add here. This actually ends up being a catch-all category for all things related to session management.

I don't think I can emphasize enough the importance of using the container's session-management system, if at all possible. If not possible, re-engineer the application until it is possible. No matter how smart you think you are, home-grown session management works about as well as home-grown cryptography - it's only a matter (short) of time before it's broken.

There are actually lots of sub-flaws that end up in this category for whitehats to look for:

• Does logout actually kill the server-side session?
• Does logout actually delete the client-side cookie? (If you do the first, this should be a non-issue)
• Can the client somehow tell YOU the session token, and the server take it? (This is a session fixation attack, and I can't tell you why, but some sites are implemented in such a way that it actually works. Sheesh.)
• Does logging in give you a new session token? (This is hard to implement sometimes if you're using the containers session management, unfortunately.)
• Can two of the same user be logged in simultaneously? (May or may not be a risk - that's up to you.)
• Are the session timeouts (time between requests and absolute timeout) appropriate for the sensitivity of the information you're providing?
• Are session tokens easily guessable? Some tools, such as WebScarab have session token analysis built-in, but I think they're somewhat lacking. Most of them check for the "randomness" of the session token, but if the session token is simply a hash of a number that gets incremented for every new session, or of a timestamp, or of the user ID, it's not that random.

The very best thing about this one, now, is that because of the Indirect Object Reference flaw being a separate category, typical privilege escalation no longer falls under this somewhat overlooked category.

A8 Insecure Cryptographic Storage
This is one of those categories that was always hard for me to deal with being in a listing of Web application vulnerabilities. Insecure Cryptographic Storage is neither isolated to web applications, nor is it something that can easily be tested for or fixed. But there are some general guidelines:

• Never, ever, ever use home grown crypto
• Never, ever, ever use home grown crypto
• Do not get overworked about things about MD5 or SHA-1 being broken. They are broken, but you should really only concern yourself with that for things like certificates, such that the signature is going to have to last a long, long time, and is going to be highly-available. If you have the cycles, go ahead and use SHA-2 if it makes you feel any better.
• Whenever possible, things passed back and forth with the user should include a nonce, so that it's not susceptible to replay attack. For example, if you hash the user's password on the client side to pass over so that if an attacker manages to be inside the SSL tunnel (you are using SSL for anything where the password gets passed, right?), if the attacker gets a straight hash of the user's password, they have the password itself. Use a nonce to verify that the user applied the nonce before the hash, and perform the same hash and nonce application on the server side.
• Simply don't require configuration or things like that in a web-accessible directory. If you feel like to be secure you need to encrypt configuration information, you're probably not handling the configuration information properly in the first place.
• Remember that crypto on the database or on the filesystem is useless if an attacker has access to the database, or can mimic the user that files are encrypted to. Doing database encryption doesn't really help credit card numbers if I can get sa and use a database driver (or your webapp) to slurp them all down. Encrypt individual items when necessary.