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?"
If any other language would have the same popularity as PHP, it would suffer the same problem. All the noobs that write bad PHP code would than write bad .NET/Java/Python/whatever code. With 'same popularity', I mean being used by all the noobish kiddo's that now abuse PHP.
It doesn't have to be like this. All we need to do is make sure we keep talking.
Absolutely PHP was originally for for non-programmers. It was a CMS written in Perl, for people who couldn't use the Perl templating systems directly. That was a long time ago, of course.
It was abused as a general programming language, often by people who didn't know about file permissions and couldn't be bothered to learn how to chmod 755. That wouldn't have been a huge problem if they weren't putting the scripts on web sites, for everyone to attack. That was a big problem for several years - non-programmers who didn't want to learn an actual programming language wrote PHP scripts and PUT THEM ON THE INTERNET. It wouldn't really have been a big deal if they wrote scripts for their own desktop or for their local intranet.
Now that PHP has been used as a general-purpose web programming language for several years, it has been significantly updated to better fit that role. Current PHP is much, much better than it was a few years ago. It's still relatively easy, though, so it -can- be used by people who are clueless. But now it's also used, correctly, by people who are actually competent.
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.
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()?
To be fair to PHP here, the mysql_escape_string vs mysql_real_escape_string is mostly MySQLs fault (watch http://www.youtube.com/watch?v... if you want an insight into how screwed up MySQLs development was). It's one of their old C libraries that added the mysql_real_escape_string function.
PHP is not entirely blameless on this front; back in the early days of PHP Rasmus Lerdorf (PHP's creator - read and weep) thought the best way to design an API is to just expose PHP's internal libraries' headers to PHP code, consistency be damned. That's how we got mysql_real_escape_string; Rasmus was just following past form.
PHP has had SQL injection licked for at least the past 10 years (literally every database driver except the deprecated mysql_* one supports binding values to a query), it's just that all of the tutorials are utter, utter garbage and STILL use mysql_* functions.
mysql_* is dead as of PHP 7 (which is pretty imminent now), thank god.
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.
It comes from the top down. Try running PHP's own tests some time. You'll be utterly unsurprised by the result. They're also written in PHP, which I feel is perhaps something of a design flaw.
I think you're confused. They weren't "writing code to handle apostrophes". They wrote a code review-related microapp, and I noticed during the submission of a review that it failed, gave an detailed error message (which I should probably warn him is also bad practice, you don't help would-be hackers out by publicly such information) indicating a particular bad SQL statement, and the statement was "bad" because it wasn't sanitizing the apostrophes in my input. It was immediately clear that he was building his query through simple string concatenation.
The application was designed for internal usage (though I'm not sure if it was externally accessible)... but even if it wasn't externally accessible, the fact that he would write SQL queries through string concatenation is a problem, in case he ever would write an externally-accessible application for us. I'm not disappointed or upset with him or anything, because lots of people do that, it's a natural way for someone who doesn't realize the risks to do it. People are used to building up strings through concatenation - for example, for displaying text in a GUI. A large chunk of programmers just don't know the risks that exist in certain contexts.
Hello from Sputnik 2. I am receiving you.