20070221

OWASP Top 10 2007 Update RC1 - A7 A8

Link

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.

2 comments:

  1. 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.


    You actually did raise a few points for A7. This is probably the most difficult category to read through in the 2007 Top 10.

    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 is also the problem of application developers writing in "exceptions" to authentication or session management.

    There are actually lots of sub-flaws that end up in this category for whitehats to look for:
    Can two of the same user be logged in simultaneously? (May or may not be a risk - that's up to you.)


    Reversely, by not allowing the same user to be logged in simulatenously it could end up denying that user to the application, or putting them in a login loop.

    Speaking of these sorts of exceptions, I think it should be noted well that:
    1) Many application developers write in their own exceptions based on multiple-factors including:
    a) IP address-based authentication
    b) DNS-based authentication
    These work in a similar way to spoofing the HTTP headers for referer, but at the network level. For b), it could be either forward or reverse DNS

    2) Wildcarding exceptions may cause authentication bypasses
    a) Email addresses can cause this: e.g. joe@paypal.com@joesdomain.com or joe@paypal.com.joesdomain.com
    b) IP address or prefixes in the authenticaiton / session managemnet e.g. 10/1/8 vs. 10/8 (if 10/8 is allowed), 10.0.0.210.0.0.1, etc
    But I guess #2 is more of an input validation problem that affects authentication, although these could be inside cookies or other contained session management, as well

    Testing these should be done by fuzzing the internal and external parts of the application(s) responsible for authentication, looking at the full IP header and not just the HTTP header, as well as varying email addresses or other places common for exceptions (the username, any part of a cookie, etc)

    ReplyDelete
  2. dre: Excellent points! Like I said, there are a ton of sub-flaws in the category. Like I didn't say - there are probably enough of them that I would certainly leave out something. Just wanted to bring up some of the common things that are overlooked. And you certainly brought up a couple of other items that are a) common, and b) overlooked.

    Thanks for keeping me honest.

    ReplyDelete