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.