Logic flaws issues in web applications are much different. They range from simple bugs shown in a few lines of code, to complex security vulnerabilities starting from the interoperation of several core components of the application. In some situations, they may be simple and easy to detect; in other cases, they may be exceptionally subtle and liable to elude even the most rigorous code review or penetration test.
Unlike other security vulnerabilities such as SQL injection or XSS, no common “signature” is linked with logic flaws. The defining point, of course, is that the logic implemented within the application is incomplete in some way.
In many situations, the flaw can be described in terms of a particular assumption that the developer made, either explicitly or implicitly, that turns out to be flawed. In general terms, a programmer may have reasoned something like “If A happens, then B must be the case, so I will do C.” The programmer did not ask the entirely different question “But what if X occurs?” and therefore failed to consider a scenario that violates the assumption. Depending on the circumstances, this flawed assumption may open a significant security vulnerability.
Web application vulnerabilities have grown in recent years, the incidence and severity of some categories of vulnerabilities have declined noticeably. However, because of the nature of logic flaws, it is unlikely that they will ever be eliminated via standards for secure development, use of code-auditing tools, or normal penetration testing. The diverse nature of logic flaws, and the fact that detecting and preventing them often requires a good measure of lateral thinking, suggests that they will be prevalent for a good while to come. Any serious attacker, therefore, needs to pay serious attention to the logic employed in the application being targeted to try to figure out the assumptions that designers and developers probably made. Then he should think imaginatively about how those assumptions may be violated.
