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?"
Even older programmers do it - I discovered just last Friday that a senior programmer I work with had written a service that was vulnerable to SQL injection (purely by accident, I was using it and noticed how it was mishandling apostrophes).
I think most programmers will do it sooner or later until either they've A) internalized the warnings from others, or B) been caught by someone noticing (and potentially exploiting) vulnerable code that they've written. And if neither A) nor B) happen immediately, they may well be serial abusers.
Also a lot of programmers seem to forget that injection doesn't just apply to SQL. Shell command insertion is also a huge abuse target.
Hello from Sputnik 2. I am receiving you.
Because typical PHP tutorials still teach old, broken ways of doing things and this shows no signs of abating. Go ahead and search the web for things like php mysql tutorial. The top hits are crap like this, written by incompetent developers who don't know what they are doing. PHP developers learn from crap like that, then they go on to write their own tutorials that are the same or worse.
And before you start, yes, this is something where PHP is stand-out bad. Go ahead and try the same searches with other languages. There is a vast difference in quality of learning materials. I mean, PHP had XSS vulnerabilities in its official tutorials until relatively recently. Newbies don't stand a chance in those circumstances.
Bogtha Bogtha Bogtha
It's irresponsible to continue to do this. With stored procedures, ORMs (there are some good ones out there, I use Linq a lot), and parameterized queries available in all the major languages I can't help but wonder if people are just incompetent.
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!
Chance favors the prepared mind.
Perfect is the enemy of good.
It's irresponsible to continue to do this.
I was browsing Stack Overflow the other day and looked at an SQL/PHP based question. The poor guy asking the question was obviously a n00b who was just starting to code, and had googled around to find a solution to his problem but it wasn't quite working for him (and hence the SO question).
From what I saw the problem wasn't that he was a stupid n00b, it was that his googling had turned up horrendously bad PHP code (using ancient DB connection style code, plus totally SQL injection ready) and he didn't know the difference between that code and best practices. So it seems that part of the problem is the act of using google itself and how good code and bad code examples are presented as equals solely based on what ever google's page rank algorithm de jour is. And I can't see how you can fix that without purging google of all the bad code examples.
I am Slashdot. Are you Slashdot as well?
You are absolutely right. I see this all the time as the hiring manager in a web shop. I always present candidates with this question:
1. Find and fix the potential SQL injection vulnerability: // .. /*@var \PDO */ //..
protected $dbh;
public function getOption($name)
$sql = "SELECT val FROM options WHERE name = {$name}";
$stmt = $this->dbh->prepare($sql);
$stmt->execute();
return $stmt->fetchColumn();
}
For those who don't know PHP, the answer is:
$sql = "SELECT val FROM options WHERE name = ?";
$stmt = $this->dbh->prepare($sql);
$stmt->execute(array($name));
Almost no candidates out of school even know what I'm asking them to do. About half of people with experience get it right; a quarter of them understand the question and get it wrong, and a quarter don't understand the question. I find that it doesn't matter how many years of experience they have, about a quarter of programmers just don't understand what SQL injection is.
I just don't get it. I've spent more than a decade programming in PHP, the language that really made SQL injection a thing because it lacked prepared statements for a long, long time and even then a lot of the input escaping functions were broken. Over those years, I've picked up a lot of bad habits; some were dictated by the shortcomings of PHP4 ("dependency injection? what's that?"), others are a side effect of spending all of my time cranking out single purpose scripts that had to work yesterday ("Ctrl+C; ctrl+V").
Nevertheless, it still blows my my mind when I encounter people in this day and age who aren't using prepared statements. Concatenating SQL is just so... messy. Seriously, it takes two minutes to write a nice, clean, understandable SQL statement as a string, and at most a three line loop to bind the values. If your are concatenating it together, you have a mess of loops and conditions (comma here?) and strings and array manipulations... It is so much more work.
Yet I still hire jokers who can't do it because I need bodies to fill seats.
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.
Because businesses think software development in general, and especially web development, is easy. They hire monkeys and pay peanuts (or sometimes even serious dollars that could get them quality of they could recognise they were being taken for a ride), and we continue to see the most basic errors being repeated across most web sites. Seriously, the quality of web developers generally is absolutely appalling.
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.
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.
As soon as PHP totally gets rid of the mysql_ family of functions, and forces everyone to convert to mysqli function/objects or PDO, it will fix itself. As a bonus, quite a few folks may make some beer money fixing all of the suddenly broken scripts...
The problem with search results is that the mysql_ functions for a loong time were the only way to do the task, and with the plethora of tutorials/information out there the sheer number of them overwhelm the "new" stuff (mysqli and/or PDO)
Don't blame me, I voted for Kodos