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.

OWASP Top 10 2007 Update RC1 - A5 A6

A5 - Cross-site Request Forgery (CSRF) - Editor's note, I call it XSRF, but I've also seen Session Riding and a couple of other names. Go ahead and get them all confused. Unless all malicious actions are somehow of benefit to the attacker, then I'd probably remove the statement "to the benefit of the attacker". This can also be used for DoS, or getting the carrier to do anything under their own privileges.

The recommendations are pretty sound, but I would certainly flesh them all out. With the first item, you need to focus on those locations where XSRF also exists. Yes - you should get rid of all of them, but start on those - particularly if your request token is specific to the action, not the session. The third bullet should be fleshed out more to specify how to re-authenticate. This can include just asking for the password again, a CAPTCHA, or one-time password. And using GET over POST really doesn't do much at all to help.

A6 Information Leakage and Improper Error Handling - Another sort of catch-all that leads to flaws like A4 (particularly when there's key exposure or filename information). One global 500 configuration I've seen that's very effective is that each application error generates a unique instance ID - I don't mean for the class of error, but the exact occurrence. This way, a user who calls the help desk can give an ID and support teams can trace logs by a unique ID. Of course, this same ID could just be emailed to the support team.

It's also very important that you configure every layer of your error handling to look the same. For example, exceptions handled by Struts can be configured in the struts configuration. But what if the attacker calls a method that makes the framework puke? Then you get a 500 error handled by the app server. Even if you make the error screens look precisely the same, generally an application error in Struts returns a 200, while a Struts error returns a 500 - so you'll want to make sure your global exception handler throws a 500 and returns no content - this way the app server's 500 will be displayed. (The proof is left as an exercise for the reader).

OWASP Top 10 2007 Update RC1 - A3 A4

A3 - Malicious File Execution - or is it Insecure Remote File Include? The names are used interchangeably in the document, which is annoying. By looking at the name, they appear to mean entirely different things. And equally irritating is that it appears to be the same flaw as A4, except A4 could also include key exposure.

The more I read it, it appears that this is supposed to be inclusion or execution of things that are not supposed to be part of the web application at all, which would make it just another injection attack (see A2). But I'm odd in the way I want to categorize things. Or on another read, it appears to imply that actual code submitted by users is to be executed by the web server - even more shocking that people would somehow find a legitimate need to do this.

One of the recommendations there is to use a level of indirection, but it's very far down on the list. You as a developer know what it's okay for a user to access, so make sure to abstract that so that the user doesn't get to tell you what they can do.

With the confusion I have between this and A4, I'll have more interesting things to say about...

A4 Insecure Direct Object Reference
Again, this appears to be the same as A3, but A3 seemed to be really really focused on PHP type flaws (although they say you can do similar things with .NET or J2EE apps). The Verifying Security section implies that static analysis tools can't determine what does and doesn't need access control, but from my experience, all of them will flag places where filename injection can take place, and where key exposure takes place -this is a far safer approach when you get false positives, rather than false negatives, although it does require a manual analysis of the results to determine what is acceptable.

What's funny about the example is that while SQL Injection isn't possible because they use parseInt on both parameters, you still should use parameterized queries on every single query, without fail. There are more reasons to use parameterized queries than just to be rid of SQL Injection, and to make recommendation in one place to use them, then to fail to do so later makes the document look really really bad. What if "cartID" becomes a CHAR type later on?

Fortunately, both of these flaws recommend a level of indirection as a good fix. Unfortunately, I can't tell enough difference between the two vulnerabilities to actually call them different vulnerabilities. These types of unclarity will make those who don't always look at the document (developers) run away from it.

OWASP Top 10 2007 Update RC1 - A1 A2

A1. Cross Site Scripting (XSS)
While this is probably the most widespread of attacks against websites, it's actually just that - an attack or threat. And it falls under the category (IMO) of Command Injection. Well, okay, to be fair, Cross-site scripting would imply injecting script from another site into a different one. What we call Cross-site Scripting is probably more accurately called HTML injection or script injection. But we stick with the name we're given, which somehow implies it's a different concern than command injection. This misnaming is not OWASP's fault. And it's probably not their fault it's mis-classified.

Because it's so serious, maybe it ought to be in its own category...

I agree with the fixes (finally! whitelist, and output filtering!), but the encoding needs to take place at two levels:

1. (X)HTML (or whatever presentation format) encoding, meaning encode dynamic markup into the appropriate entities.
2. Specify output encoding. It seems this gets lost in the shuffle, but there are PoC's now for applications that expect or accept one encoding and either don't specify the output encoding or specify the wrong one.

This is probably as close as we're going to get in a summary document like the Top 10. And because the whole industry calls it Cross-site Scripting (even when it's not), the name needs to stay the same so developers can find solutions. (I'm assuming a search for "Cross-site Scripting" will return a bunch more hits than "HTML Injection").

A2. Injection Flaws
Injection Flaws is the bucket for all the remaining (not XSS) injection flaws. This includes SQL, command, LDAP, XSLT, you name it. Because of SQL injection alone I can see this as #2 on the list. Not necessarily second-most dangerous, but it can still be found semantically, or with google dorks.

Again, the recommendations are almost spot-on. But there's not much detail they can go into without breaking down the different types of injection. I really don't like the statement that "validation is still recommended in order to detect attacks". Validation should be used to determine anything that isn't what we expect, not to try to find attacks.

More on A3-A10 later...

OWASP Top 10 2007 Update RC1

Well, it's been three years coming, and the OWASP Top 10 is about to have a new revision. This version has some major improvements over the 2004 version, but some of the same problems are still there. I'll give a high-level overview of the improvements here and in future posts go over individual items in the Top 10 as I get more time to really digest the document.

Although security practitioners tend to gravitate to other taxonomies of threats, vulnerabilities, flaws, weaknesses, attacks, etc., the OWASP Top 10 is a very well-known listing of common web application vulnerabilities. So when you present your findings to a customer, you end up trying to shoe-horn your findings into one of the Top 10, which generally isn't hard because in the old version, there are some really broad categories. Most web developers have at least seen the OWASP Top 10, but might not have seen some of the more complete or better-structured taxonomies.

Major improvements:

• Most of the recommendations are substantially better. Most of them recommend using output filtering or a protecting API. For example, the XSS recommendations are business rule input validation, output filtering, then whitelist not blacklist. SQL Injection, they recommend parameterized queries, rather than input validation. (Look out WAF vendors!)
• Most everything looks more like what we call "vulnerabilities" now. I still consider command injection, cross-site scripting, etc. to be threats, not vulnerabilities, but worded properly, you could say "vulnerable to Cross-site Scripting". While still not perfect, it's a major improvement of the previous hodge-podge of threats, vulnerabilities, and best-practices.
• All the vulnerabilities are actually web-specific vulnerabilities now. While buffer overruns could potentially occur in web applications, I'm not so sure they were one of the 10 most dangerous flaws in web applications, and I know they weren't specific to web applications.
• Most of the vulnerabilities come from the MITRE Vulnerability Trends, rather than from some list from somebody's head.

Now for the stuff that didn't improve:

• Some specific items are still truly a subset of other flaws. For example, Cross-site scripting is its own vulnerability, not considered a subset of Command Injection. XSRF has its own vulnerability, it's not a subset of session validation (not positive that's necessarily wrong - the whole point of XSRF is that it works in spite of session checks, but I digress....)
• It still mixes threats with vulnerabilities. Cross-site scripting is something the bad guys do (threat). Insecure Cryptographic Storage is something the good guys fail to do (vulnerability).
• It actually includes language and/or framework specific fixes. While this is a good thing, OWASP doesn't have a governing board of approving recommendations from the community of additional framework-specific fixes, so you're limited to recommendations the authors could come up with. If your developers read this, they may conclude the listing of fixes is exhaustive. I recommend they have an approval panel and allow the community to submit recommendations based on language, platform, or framework. (I know, this is not what the Top 10 is for, but developers do come here first for their recommendations on how to solve the problems.

As I get to read the individual items, I'll post comments here. It's RC1, so there's still time to fix things, but this is markedly better than the 2004 release.