While the industry is buzzing with XSS, SQLi, CSRF, browser insecurities, etc., Business Logic Flaws (pdf) is the website security dark horse no one talks much about. You know those all to common issues where you can jump into someone else’s online accounts or access confidential data with a normal looking request simply by flipping a few characters. Business Logic Flaws are challenging to discuss, prevent or even fix generically for that matter because they’re extremely website specific. We recently released a white paper that’s all real-world-example driven to help people begin thinking out of the box about their own websites. Snippet:
"Session handling, credit card transactions, and password recovery are just a few examples of Web-enabled business logic processes that malicious hackers have abused to compromise major websites. There are many forms of business logic vulnerabilities commonly exploited by attackers. These vulnerabilities are routinely overlooked during QA because the process is intended to test what a piece of code is supposed to do and not what it can be made to do. The other problem(s) with business logic flaws is scanners can’t identify them, IDS can’t detect them, and Web application firewalls can’t defend them. Hardly a winning trifecta. Plus, the more sophisticated and Web 2.0 feature rich a website, the more prone it is to have flaws in business logic due to the complexities involved."
Examples I use:
1) Winning an Online Auction
2) “Interactive” T.V.
3) See Steve Jobs up close
4) Day trading contest for $1,000,000
5) The house almost always wins
6) Password Recovery
7) Making millions by trading on semi-public information
Enjoy!
9 comments:
My last 2007 prediction from the beginning of the year (http://www.greebo.net/2007/01/06/webappsec-past-and-future/) is starting to come true! And from a scanner vendor! Sweet!
Seriously - nice work. More needs to be said on uber important topic. This is how I've been doing code reviews for the last few years, and if scanners can do some of the heavy lifting, all the better.
I primarily target the golden apples in my reviews. The low hanging fruit falls out as a consequence of looking at how to steal or spoil the golden apples.
Andrew
Don't forget Operation Flyhook. Ivanov and Gorshkov performed an amazing business-level hack against eBay, Paypal using some perl-bots. Without violating any security rules and spoofing some very basic technical protections, they created a multi-million dollar credit-card laundering business.
Good paper. If you're going to send this out to customers etc you might want to change the font size on the last page. The title appears fine but the blue text (topic) of each paragraph it's hard to distibguish "i" and "l".
I encoutered a good one last year. I was working with a system which did license registrations and allowed you to make a donation to a related charity. Assume your license fee was $65. You could make a "charitable donation" through the web form of -$64, resulting in a total owing of $1. Couldn't reduce to zero or negative but I'd much rather pay $1 than $65 :) There were two very sad points along with this discovery. 1) You could do it right within the web form (no need to tamper the transaction "in-flight" or anything), 2) The client supposedly had a test case for this condition :( Oops!
@Hi Andrew, thank you, glad you liked it. The only way my predictions comes true is if they're self-fullfiling. :) As much as anything else, I view my job as helping customers make their websites as hard to break into as possible. If that requires scanning technology great... security experts, fine...WAFs, ok then. I jus think its time to be pragmatic about what we can expect from each technology/process and measure them accordingly.
These business logic flaws though really present a huge and challenging problem. I mean, how and when in the SDLC do we attempt to find them? Some are of course introduced early in the design phase while others only show up during implementation. Plus there is no generic and reasonable approach to identify them (guidance) and we're completely reliant upon clever people to spot them. So as you say its time to start raising the issue now because the more smart people thinking about it the better.
@r Operation Flyhook? I've not heard of this. Got a reference I might read?
@Thorin, hey thats cool! We might have to give that a shot more often and see what happens. Reminds me of that old bank wire transfer hack where you enter a negative amount. On some systems if will actually pull money out of another account instead of adding to it. :)
@vanderaj -- sheesh "from a scanner vendor" :)
Who all do you think works over here? We're the ultimate pragmatist crowd....
I hear ya' though. Some folks don't wanna touch this subject with a stick b/c they either (a) don't really understand it, or (b) know their automated parsers cannot find this stuff.
You can do A LOT of cool things with automation once you get a human eyeball parser involved to add context, and being able to process out of band comms like SMTP helps too. :)
Oh Andrew, by the way, I've been discussing business logic flaws publicly for quite some time:
http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1189767,00.html
http://jeremiahgrossman.blogspot.com/2006/12/business-logic-flaws.html
Its the other guys you have been conviently ingoring the subject. :)
A friend of mine once provided me the following quote:
"Testing is making sure the product does what it is supposed to do. Security testing is making sure the product does what it is supposed to do, and nothing else!"
He is not quite sure where he picked it up from, but it is one of the few quotes that I can even remember. I haven't read your new paper yet but plan to.
I've seen that quote around as well and I like it. The problem is its hard to know what a piece of software can be made to do.
I have gradually become the great fan yours and I wish you good luck for your success.
Post a Comment