Friday, February 1, 2008

How to tell your WebAppSec program has failed you...

Reference: http://thedailywtf.com/Articles/Not-Exactly-AJAX.aspx

A friend of mine often sends me links to this site and sometimes I read them, sometimes I don't. For some reason I read through this - and it immediately hit me. This Web App Sec program failed, big. You may be saying to yourself, "Self, it doesn't even look like there is a Web App Sec program here!" Bingo.

Not to point out the obvious - or even to pick at the stupid, but let me point out the 3 deadly sins that this "programmer" committed.
  • First, he or she is building SQL statements on the fly. If reading about the latest web hack and data compromise should have taught you anything, it's that you never, ever, under penalty of death construct SQL statements on the fly like this. Yes, there are special cases, but those have to be very carefully thought-out and planned, and secured... this obviously is not one of those cases. SQL injection anyone?
  • Second, the User ID and password in the code. Viewable in your browser (at the client!) by going to view source in whatever browser you're using. If you as a developer are still relying on the "it's not there in plan text on the page, no one will see it", dig your head out of the sand and kiss your a** goodbye. That mentality became obsolete about 8 years ago and anyone who codes this way should have their keyboard permanently taken away.
  • Lastly - You have, obviously, a database server out on the Internet. Forget SQL injection, how about firing up your favorite SQL front-end (for MS SQL Server here) and doing database calls directly. Let's just cut out the middleman, save ourselves the trouble of "hacking into" the database and go straight into full database devastation mode. Incredible.
So what have we learned by seeing this absolutely atrocious piece of code? Better, could it have been prevented? The answer is an emphatic yes - and here's how, using some very simple logic and process. If you don't recall the 3 components of any good solution, they are the P P T or People, Processes, Technology that make solutions viable and workable. Here's how PPT could have saved this deadly piece of code:
  • People: (1) Trained developers rarely write stupid code like this. (2) Even if they do, having someone double-check their work, or "cross-check" will eliminate 99.9% of "stupid" coding errors.
  • Process: (1) A proper SDLC methodology would typically prevent a tragedy like this by providing for a structured approach to development, reviews of code, cross-checks, and audits along the way to producing production applications. (2) A formalized process is repeatable, and thus reinforces good habits and intelligent thinking - and learning from mistakes of yourself and your peers.
  • Technology: Either a static code or hybrid analysis tool (like Ounce Labs, Fortify SCA, or DevInspect) or Application Security Scanner (like HP's WebInspect or Watchfire AppScan) would have caught this egregious error in judgement. Other analysis and scanning software is also available out there which could have caught this as well!
What are we to learn from all this?
  1. Software developers are very seldom security-conscious, and will write bad code given the chance. (Remember, bad doesn't necessarily mean it doesn't work right; the application may work great with proper inputs and no malicious intent - but this software is easily breakable!)
  2. Developers need help. Get them trained, give them resources like a formal development process and tools to check their code
  3. Your bad code will be analyzed. Whether it's someone like me, someone at the DailyWTF, or someone trying to steal your data. It would be intelligent to make sure you or someone internal to your company is the first to find critical defects before they become catastrophic to your business.
Good luck.

1 comment:

Cameron said...

I AM a software developer and whilst I don't think I have done anything that nasty previously, I certainly have done plenty of SQL injections in my code before. It all comes back to jr vs sr and the timeline that management expect you to complete this task on. These days I assume that every visitor is some l33t hacker and validate all input and use prepared statements and many other things however when you are a n00b programmer, you just don't know where to begin, you get hit with these stupid TLA's like XSS and CSRF and are expected to learn them all inside out immediately...

Sadly it just doesn't work that way!

That said, doing things client side should be pretty obvious of a thing to stay the fsck away from, different browser version is enough to blow up major client side things and the more people who use it the more things there are to blow up on you!

Google+