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.
- 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!
- 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!)
- Developers need help. Get them trained, give them resources like a formal development process and tools to check their code
- 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.