Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

When an attacker uses state of the art techniques to get through your security, you curse them and then redouble your efforts at security.

When an attacker uses rudimentary techniques that have been well known for many years and have straightforward and low-cost counter-measures, then you should rightfully be disgraced. More so if you are a security company.

It's not as though the attack against HBGary was like some expert safe-cracker routine. Rather, it was more similar to someone walking up to the front door, finding it locked, then finding a key under the doormat and letting themselves inside. There's no excuse for that. Not if you have any sort of obligation to maintain a level of security and secrecy.



I consider this instance to be a step worse, given that you have to actively work against the tools available to create an SQL injection vulnerability (or at least take extra steps to work around the easy way of operating).


I wouldn't go quite that far. In PHP, for example, it's still the most straightforward way to use dynamic sql statements built up as concatenated strings. It's easy enough to skip input sanitation here or there on accident.

That being said, there's absolutely no excuse for that sort of slap dash engineering today. It's dead simple, even in PHP, to use input sanitation, or to use parameter binding / prepared statements to avoid SQL injection vulnerabilities. Those sorts of best-practices have been well known for at least the last half decade.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: