Web application vulnerability scanners are *not* the silver bullet. If you didn't know that already odds are you've got bigger problems than what I'm about to talk about ... but most folks understand that scanners have their limitations. Logic flaws within web applications is one of those limitations to the automated black box (dynamic) scanners.
Logic flaws typically involved, you guessed it, flawed application logic within the code, or a application flow that is unintended. Ha.ckers.org has a great example of a Yahoo issue some time back, which exposed the company to potentially serious financial loss. I can think of another excellent example as well...
Think about this. You see an ad in the paper, or on the news from a local bank. They're offering you $50 for opening a new account and depositing $1,000 into it, on their online website. You figure, free money is free money. Of course there is a catch, the fine print says you have to keep the account open for a minimum of 30 days, and have at least a $1,000 balance during that time. Fair enough right? Now consider someone trying to subvert that system. That person opens up an account, deposits the necessary $1,000, and the system auto-debits the $50. The person then goes to immediately withdrawls all but $1. Logic would dictate that this account should be over-drawn at this point by $49, since the bank would want its $50 back, right? If the software isn't coded properly (and doesn't immediately notice the $1 balance) the user could then deposit another $1,000, get another $50, pull out all but $1, and repeat the process getting free money! Things like this have happened before.
What if your bank allows you to have multiple sessions open (meaning, log in more than once at the same time) and you can deposit $1,000 with one, then withdrawl that same amount from BOTH sessions... you could conceivably scam the bank for an extra $1,000... now we all know banks aren't this stupid, right? But you get the idea.
The first question that comes to mind that customers have asked is - "how do we scan for and identify those vulnerabilities?" The simple answer is you don't. There aren't any tools, that I'm aware of, that can think for themselves to find flaws in logic... at least not yet. So that brings us back to the question - how can we find these flaws?
The question is much more simple than the answers... in fact, there is no single answer that I can offer, except a methodology that may help you. Follow these simple things to help mitigate the risks that logic flaws pose...
- Always have a logic-flow diagram (based on actual intended use-cases) before any code is written
- This should be written by the business analysists, not IT people!
- Continually re-visit that logic-flow diagram with the architecture team responsible for the building of the application at hand
- Make sure things haven't changed throughout the SDL
- When it comes time to audit the application, have that logic-flow in front of you and analyze it for potential abuse-cases
- Build a parallel abuse case diagram alongside the logic-flow (use-case) provided by the business
If you haven't caught on yet - the magic here lies in having a properly-built logic-flow (use-case) diagram to reference from the business analyst. Ask yourself... do you have one for every application you security test? If you answered no, now may be a good time to start. If you'd like to know more - contact me directly and I can help.
Posted
01-28-2009 12:00 AM
by
RafalLos