Information in this Chapter
How does the site work? This isn't an existential investigation into the Web application, but a technical one into the inner workings of policies and controls that enforce its security. Sites run into technical faults such as cross-site scripting (XSS) and SQL injection when developers fail to validate data coming from the Web browser or assume a misplaced level of trust in the user. Logic-based attacks work differently. There is still a malicious user on the other end of the HTTP connection, but this time, the attacker is searching for errors in workflows or trying to skip the straight line from point A to point B by making requests out of order.
Anyone can exploit a vulnerability in the workflow of a Web application. These attacks do not require knowledge of JavaScript or any particular aspect of HTTP. An attacker doesn't need to know whether a request is sent via GET or POST. Most of the time, the attacker doesn't even need to know the syntax of a URI or have to modify a query parameter. In many cases, the attackers are the Web equivalent of shoplifters, fraudsters, or pranksters. Possibly, the only thing they have in common is guile and a curiosity about some aspect of a Web site. This represents quite a different threat than other attacks predicated on an understanding of SQL statements, regular expressions, or programming languages.
The attack signatures for these exploits vary quite differently from other attacks we've covered throughout this book. The attack might simply be some legitimate requests repeated several times or in an order that the Web application didn't expect. For example, imagine an e-commerce site that sells books. Maybe the site regularly offers discounts through partners or sends discount codes to shoppers to bring in their business. The site's normal workflow might involve steps such as follows:
An enterprising attacker might set up a dummy account and pick a book at random to take through the checkout process. The attack would proceed through step 4 (probably using a fake shipping address). Once at step 5, the attacker could guess a coupon code. If the result in step 6 shows a price reduction, then count that as a success. If not, then go back to step 5 and try a new guess. This process might seem tedious, but it's easy to automate these requests so that with a few hours of preparation, the attacker can launch an unattended attack that runs 24 hours a day, collecting coupons.
Now, imagine the same workflow under a different attack scenario. We'll still focus on steps 5 and 6, but this time, the attacker has a coupon. Maybe it's just a 5% discount (the 50% off coupons haven't been discovered yet by the brute force guessing attack). This time the attacker enters the coupon, checks the updated price, and then moves on to step 7 to provide a credit card. Before moving on to step 8, the Web site asks the user to confirm the order, warning that the credit card will be charged in the next step. At this point, the attacker goes back to step 5 and reenters the coupon. Because the site is waiting for a confirmation, maybe it loses track that a coupon has already been applied or the program flow that checks coupon reuse isn't triggered from this state. So, the attacker repeats steps 5 and 6 until the 5% coupon is applied enough times to turn an expensive item into a $2 purchase. Then the attacker returns to step 7, reviews the shopping once more, and confirms the purchase.
What if the attacker needed to have $100 worth of items before a big-discount coupon could be applied? The attacker might choose one book, and then add a random selection of others until the $100 limit is reached. The attacker applies the coupon and obtains a reduced price. Then, before confirming the purchase, the extra books are removed along with their purchase price, but the discount remains even though the limit has no longer been met.
Let's look at yet another angle on our hapless Web site. In step 4, a customer is asked to fill out a shipping address and select a shipping method from a high-cost overnight delivery to low-cost shipment in a week. What happens if the Web site tracks the cost and method in different parameters? The attacker might be able to change the selection to a mismatched pair of low-cost rate with high-cost time frame. The attack might be as simple as changing a form submission from something like cost=10&day=1 or cost=1&day=7 to cost=1&day=1. The individual values for cost and day are valid, but the combination of values is invalid – the application shouldn't be allowing low rates for overnight service. What if we strayed from purely legitimate values to changing the cost of the overnight rate to a negative amount? For example, the Web application subtracts $10 from the total price, but for some reason it casts −10 to its absolute value when it verifies that the shipping rate, 10, matches the day value, 1.
The previous examples relied quite heavily on conjecture (although they are based on actual insecurities). Logic attacks involve a long string of what-ifs whose nature may be quite different from the childhood angst in the poem Whatif by Shel Silverstein from his book A Light in the Attic, but nevertheless carry the same sense of incessant questioning and danger. You'll also notice that, with the exception of changing a value from 10 to −10, every attack used requests that were legitimately constructed and therefore unlikely to trip monitors looking for more obviously malicious traffic. The attacks also involved multiple requests, taking more of the workflow into consideration as opposed to testing a parameter to see if single-quote characters can be injected into it. The multiple requests also targeted different aspects of the workflow. We could have continued with several more examples that looked into the site's reaction to out-of-sequence events or possibly using it to match stolen credit-card numbers with valid shipping addresses. The list of possibilities isn't endless, but logic-based attacks, or at least potential attacks, tend to be limited mostly by ingenuity and grow with the complexity of the targeted workflow.
The danger of logic-based attacks is no less than the more commonly known ones such as XSS. These attacks may even be more insidious because there are rarely strong indicators of malicious behavior – attackers don't always need to inject strange characters or use multiple levels of character encoding to exploit a vulnerability. As we'll see throughout many of the examples in this chapter, attacks against the business logic of a Web site have a wide range of creativity and manifestation. These vulnerabilities are also more difficult to defend and identify; there is no universal checklist for verifying a Web site's workflow. There are no specific characters that must be blocked or common payloads that can be detected. Nor are there specific checklists that attackers follow or tools they use to find these vulnerabilities. Yet, even the simplest vulnerability can cost the Web site significant money.