Comments on the talk made by Rafal Los (HP) about business logic flaws at Blackhat

Recently I've stumbled upon a talk on business logic vulnerabilites (whitepaper available here) made by Rafal Los at BlackHat Europe. Being a guy personally interested in the topic I decided to share my thoughts (rather critical) on the subject. I have divided my thoughts into two categories.

Inaccuracy in wordings and definitions.
1. The definition of business logic flaw is too general to be useful.
"A defect that exposes the component business processes or component flows to manipulation from the attacker perspective to achieve unintended and undesirable consequences from the design perspective; without disrupting the general function or continuity of the application."
Well, almost every application uses a so-called internal state to carry out its operations. In general, every web application workflow is a sequence of computational steps. Each computational step can be guarded by a predicate on the internal state. Hence, modification of internal state can alter a web application workflow by enabling other computational steps or disabling particular ones within it. Thus, every flaw in web application, which could be used to alter the internal state of web application may lead to attacks satisfying the definition presented by Rafal. SQL injection is the best example here.

2. 'Taxonomy' is a wrong word.
The confusion starts from the point where Rafal has introduced the term "taxonomy". Talking about taxonomies is dangerous. One have to prove the properties of the proposed taxonomy or at least try to. Rafal introduces a taxonomy of business logic flaws which consists of two classes. Neither criteria which were used to create those classes, nor a classification procedure were provided.
After all, Rafal is mixing several terms: a vulnerability (which is an enabling property of a software for a successful attack), an attack (one of the possible manifestations of an exploitable flaw) and a goal of an attack (what an attacker wishes to achieve). The same goal could be achieved through different vulns; a single vuln could be exploited for different goals. Rafal ties the first class of business logic flaws to "privilege manipulation", which is a goal. IMO this is wrong approach - this goal could be achieved through different attacks (and underlying vulns): SQLi (login bypass through injection), forceful browsing or even server misconfiguration. How does these relate to business logic?
The same applies to the second class, which is "Transaction Control Manipulation".
Finally, OWASP Top 10 is not a taxonomy and never meant to be. It is just an ordered list.

Doubts related to the proposed ideas
A method intended to find business logic flaws should operate in terms of the business domain and application logic. Hence, the first problem, which should be solved, is mapping of a set of possible interactions with web applications into use cases (which would be the basis for further analysis). It is not possible to automate this step without specification (not to mention technical issues like form submissions & captchas).
Ok, let's suppose we have solved the first problem. Now the second question is: how does the proposed approach differ from the known Q&A methods like fault injection, tests mutations, etc? Could you point out the added value of the proposed approach?

Final words
And in the end I'd like to point out the previous researches in the area, which Rafal hadn't mentioned in his white-paper:
- Differential analysis and its variants. This technique was described in several sources [1], [2], [3] and was designed for finding improper access control implementations. This means that from the methodological point of view the problem of detecting improper access control is already solved. Btw, some of these ideas were implemented in IBM AppScan, AFAIK.
- "Toward Automated Detection of Logic Vulnerabilities in Web Applications". A good example of how business logic flaws could be formalized. Not a black-box approach though.
- "Multi-Module Vulnerability Analysis of Web-based Applications". An example of how a notion of "intended workflow" could be formalized. Not a black-box approach though.

References
[1] J. Scambray and M. Shema, Hacking exposed: Web applications. McGraw-Hill Osborne Media, 2002.
[2] O. Segal, “Automated testing of privilege escalation in web applications,” Watchfire, 2006.
[3] D. Stuttard and M. Pinto, The Web Application Hacker’s Handbook: Discovering and Exploiting Security Flaws. Wiley Publishsing, 2007.