Business Logic Flaws: Party Like Its 1999

Editor's Note: This is the second article in a seven-part series by Chetan Conikee.

Attack like it's 1999

In the prior installment I discussed and described the definition of a business logic flaw.

Let us now turn back time to 1999 and recount events leading to Citibank attack on approximately 360,000 of its customers’ financial data

The company said that hackers who breached Citi Account Online on May 10 had acquired the personal information of about 1 percent of its 21 million North America customers, or approximately 210,000 credit card holders. - Wired

They simply logged on to the part of the group’s site reserved for credit card customers — and substituted their account numbers which appeared in the browser’s address bar with other numbers.

This sounds like a good old parameter tampering attack (aka forceful browsing). Even worse than that, the parameter in question sounds like it was a directly referenced account number (with predictable sequence) and that it was included in the URL of the request rather than securely placed within the body in a POST request.

This attack might sound complicated to the masses who may not be familiar with application security. It’s one of those “attacks” that anyone with basic knowledge of a browser is capable of successfully pulling off.

I’m not surprised since I still run across applications that are still vulnerable in a 1999 sort of way. Two examples:

• Molina Healthcare exploit
• Signet/Jared jewelers exploit

What conditions led to this flaw exploitation?

1. Lack of authorization checks for every user request. Web portals have several channels of communication like the browser, mobile apps, embedded links in email that track back to the portal. Are all these paths authenticated and authorized?
   
   
2. Even if authorized, are referential integrity checks performed to ensure that the account number belongs to the user.
   
   
3. Using direct object references: Account numbers are retrieved from databases and they obviously have a primary key id that uniquely identifies each of them. Rather than directly passing the account number into the user session object, one can create a transient and random account-id and cache map to the real account-id in scope of active session.
   
   
4. Don’t send sensitive information in the URL of a request: When in doubt, send parameters within the body of a POST request. This won’t protect you from this type of attack but it makes the flaw slightly less obvious.

Ironically, this is one of those types of flaws that’s all but impossible for an automated web application vulnerability scanner to find but incredibly easy for even a savvy 10-year-old to discover.

On to my next installment in this series.