Thoughts on Web Application Security Consortium

Rather than post to his own blog, Aaron Higbee decided to bait me with a link to the Web Application Security Consortium's Web Security Threat Classification guide. Uh oh, there's that magic word -- "threat." Immediately I suspected this document's use of the word "threat" in the title might be problematic, as I doubted it would be a classification of the parties with the capabilities and intentions to exploit vulnerabilities in assets.

The document description states "The Web Security Threat Classification is a cooperative effort to clarify and organize the threats to the security of a web site. The members of the Web Application Security Consortium have created this project to develop and promote industry standard terminology for describing these issues. Application developers, security professionals, software vendors, and compliance auditors will have the ability to access a consistent language for web security related issues."

That sounds to me like an open invitation for a debate on their language!

Before you get too cross with me, note that I was pleasantly surprised to see most of the content correctly framed as "attacks." Other content was not labelled correctly. Here are a few examples, which I will let you assess before I suggest an alternative way of looking at these issues.

1. A Brute Force attack is an automated process of trial and error used to guess a person's username, password, credit-card number or cryptographic key.


2. Insufficient Authentication occurs when a web site permits an attacker to access sensitive content or functionality without having to properly authenticate.


3. Weak Password Recovery Validation is when a web site permits an attacker to illegally obtain, change or recover another user's password.


4. Credential/Session Prediction is a method of hijacking or impersonating a web site user.

Can you guess which terms are vulnerabilities, and which are attacks? The attacks are easy; they are 1 and 4. The document authors correctly call number 1 an "attack" in its description. The vulnerabilities are items 2 and 3. These are easy to spot, too. The document authors didn't want to call these conditions vulnerabilities, so they bailed out by using the phrases "occurs when" and "is when". This is a sure sign that the term is not an attack, but is something else. Here are the other vulnerabilities in the document, listed as "attacks":

1. Insufficient Authorization is when a web site permits access to sensitive content or functionality that should require increased access control restrictions.


2. Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization.


3. Automatic directory listing/indexing is a web server function that lists all of the files within a requested directory if the normal base file is not present.


4. Information Leakage is when a web site reveals sensitive data, such as developer comments or error messages, which may aid an attacker in exploiting the system.


5. Insufficient Anti-automation is when a web site permits an attacker to automate a process that should only be performed manually.


6. Insufficient Process Validation is when a web site permits an attacker to bypass or circumvent the intended flow control of an application.

So, that's a great list. Add those six items and the earlier two and you have eight total vulnerabilities. At this point I would recommend breaking the document into two sections: (1) Vulnerabilities and (2) Attacks. The document itself should be renamed the Web Vulnerability and Attack Classification Guide.

If you think for a moment you can even pair attacks properly labelled in the document with the relabelled vulnerabilities above. Consider item two in this second list -- Insufficient Session Expiration. Its extended description says

"Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization. Insufficient Session Expiration increases a web site's exposure to attacks that steal or impersonate other users."

Notice the term "exposure"? That's a vulnerability that can be exploited by the following attacks listed in the guide:

• Session Fixation is an attack technique that forces a user's session ID to an explicit value. [me: like old session credentials?]


• Credential/Session Prediction is a method of hijacking or impersonating a web site user. [me: by predicting old session credentials?]


• Abuse of Functionality is an attack technique that uses a web site's own features and functionality to consume, defraud, or circumvents access controls mechanisms. [me: like insufficient session expiration?]

So there you go Aaron. I've probably angered twenty-odd more security professionals by debating their security classification program. (At least I know Mike Shema on that list, and he owes me for leaving to attend a concert during an incident response!) I'm hoping that this quote from Pete Lindstrom (who recently emailed with a link to his blog) is accurate:

"'The need for consistent technical terminology for web related security issues has a significant impact on risk assessment and remediation activities,' Pete Lindstrom, research director of Spire Security, said in a statement Monday. 'Establishing a standard approach for identifying these issues, along with a common terminology that everyone can adhere to, will help to thwart the increasing security risks associated with Web applications.'"

I would also say the Web Application Security Consortium's Distributed Open Proxy Honeypots (aka "proxypot") is an awesome idea. Again, I have no issue with the technical work by these groups, as they far outweigh anything I have done in those fields. However, I would be very happy to see industry-wide consistency in core security terms.