The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

The Nature of Logic Flaws

Logic flaws in web applications are extremely varied. They range from simple

bugs manifested in a handful of lines of code, to extremely complex vulnera-

bilities arising from the interoperation of several core components of the appli-

cation. In some instances, they may be obvious and trivial to detect; in other

cases, they may be exceptionally subtle and liable to elude even the most rig-

orous code review or penetration test.

Unlike other coding flaws such as SQL injection or cross-site scripting,

there is no common “signature” associated with logic flaws. The defining

characteristic, of course, is that the logic implemented within the application

is defective in some way. In many cases, the defect can be represented in

terms of a specific assumption that has been made in the thinking of the

designer or developer, either explicitly or implicitly, and 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 so failed

to take account of a scenario that violates the assumption. Depending on the

circumstances, this flawed assumption may open up a significant security

vulnerability.

As awareness of common web application vulnerabilities has increased in

recent years, the incidence and severity of some categories of vulnerability

have declined noticeably. However, because of the nature of logic flaws, it is

unlikely that they will ever be completely 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 are likely to

have made, and then to think imaginatively about how those assumptions

may be violated.