When discussing a web application penetration test, you will often hear of cross-site scripting, SQL injection and a number of other "classic" web application attacks. Often overlooked, but critical to an application's security however is the implementation of application logic.
Logic flaws are a significant risk for a number of reasons:
1. They cannot be automatically detected using even sophisticated automated vulnerability scanners.
2. Unlike classic input validation attacks (such as XSS and SQL injection) developers cannot prevent logic flaws through a simple piece of copy and paste input validation code, because logic flaws are as unique as the application itself.
So what is a logic flaw? Well logic flaws fit a range of issues that don't require a metacharacter to be entered. Let's take a simple example, you receive a bulk email with an unsubscribe link, the link takes you off to a URL such as:
www.junkmail.com/unsubscribe.asp?id=571823
Now, the first question is if I am user id 571823 in your system, who is user 571822? Or 571824?
It may seem simple and obvious, but the logic flaw here is that each user has an incremental/decremental ID and if we make requests to the unsubscribe script during a penetration test such as this:
www.junkmail.com/unsubscribe.asp?id=571822 then we will likely be unsubscribing other subscribers.
The Shopping Cart
Another good example is the shopping cart application. It seems reasonable enough to embed in the cart's code that price = quantity X unit price. You can't buy half of something so the quantity variable is often cast as an integer. The thing about integers is they include negative numbers. So if I order -1 of something, how will the shopping cart handle this? You will remember from school that a negative (quantity) X a positive (price) = a negative. So if the system is charging me £-6, that's a refund!
Assessment and Prevention
The only way to identify application logic flaws is through comprehensive manual assessment. An automated scanner simply cannot identify such issues. In addition, software specifications from business units should concentrate not only on what a user should be able to do, but also what they shouldn't.