Slashdot Mirror
The History of SQL Injection, the Hack That Will Never Go Away (vice.com)
An anonymous reader writes with this history of SQL injection attacks. From the Motherboard article: "SQL injection (SQLi) is where hackers typically enter malicious commands into forms on a website to make it churn out juicy bits of data. It's been used to steal the personal details of World Health Organization employees, grab data from the Wall Street Journal, and hit the sites of US federal agencies. 'It's the most easy way to hack,' the pseudonymous hacker w0rm, who was responsible for the Wall Street Journal hack, told Motherboard. The attack took only a 'few hours.' But, for all its simplicity, as well as its effectiveness at siphoning the digital innards of corporations and governments alike, SQLi is relatively easy to defend against. So why, in 2015, is SQLi still leading to some of the biggest breaches around?"
I guess you didn't read past my first paragraph? Please do.
Go and search the web for tutorials in those languages. You will find that the situation is vastly better with these languages compared with PHP.
It is - on many fronts.
Firstly, the language promoted for many, many years, a confusion between the various layers of the application. The whole magic quotes nonsense was an attempt to fix a problem relating to the database layer in the HTTP layer. This confused PHP developers for over a decade, and even though it has since been removed, it was in there for so long that an entire generation of PHP developers had their brains twisted out of shape with this confusion.
Secondly, the official documentation was super bad for years. Security vulnerabilities in the official tutorial for years, for example.
Thirdly, the API design is so bad it practically pushes unsuspecting developers into the wrong solution. addslashes()? No, use mysql_escape_string(). Oh wait, wasn't that mysql_real_escape_string()? Or perhaps mysql_really_really_i_promise_to_do_it_right_this_time_escape_string()?
Finally, the PHP community right from the very top embraces shitty practices, like ignoring failing tests in a release build. Again, a source of security vulnerabilities that simply doesn't need to happen.
Yes, you can write bad code in any language. But that doesn't mean that all languages are equal. PHP is far, far worse at this than its contemporaries and you shouldn't make excuses for it.
Bogtha Bogtha Bogtha
It's irresponsible to continue to do this. With stored procedures
Does using stored procedures solve SQL Injection? Show of hands... all of you who raised yours are part of the problem.
Also, validate and sanitize your input data man. If you're writing code for the web you *have* to do this, no excuses. Albeit, most "web developers" I've seen don't have a clue. Now, get off my lawn!
The number of people who incorrectly believe SQL Injection is in any way related to data validation means the problem will never go away. SQL Injection is a failure to enforce context and has got exactly nothing to do with content.
The data validation misinformation is so prevalent the only way you are probably even reading this is you regularly browse -1 as many of you will have modded my comment into oblivion.