Attacking Application Logic
All web applications employ logic in order to deliver their functionality. Writing code in a programming language involves at its root nothing more than breaking down a complex process into very simple and discrete logical steps. Translating a piece of functionality that is meaningful to human beings into a sequence of small operations that can be executed by a computer involves a great deal of skill and discretion. Doing it in an elegant and secure fashion is even harder still. When large numbers of different designers and programmers work in parallel on the same application, there is ample opportunity for mistakes to occur.
In all but the very simplest of web applications, a vast amount of logic is performed at every stage. This logic presents an intricate attack surface that is always present but often overlooked. Many code reviews and penetration tests focus exclusively on the common “headline” vulnerabilities like SQL injection and cross-site scripting, because these have an easily recognizable signature and well-researched exploitation vector. By contrast, flaws in an application’s logic are harder to characterize: each instance may appear to be a unique one-off occurrence, and they are not usually identified by any automated vulnerability scanners. As a result, they are not generally as well appreciated or understood, and they are therefore of great interest to an attacker.
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 vulnerabilities arising from the interoperation of several core components of the application. 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 rigorous 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.
NEXT is..Real-World Logic Flaws……………………………,,,,,,,,,,,,,,,,,,,,,,,,,,,,
