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?"
Each year brings a fresh crop of computer science graduates into the industry, barely any of them having a clue about attacks like this. Many of them will make these mistakes and learn about defending against them the hard way.
Maybe a few schools teach about this now. Maybe a few companies will pair senior devs with new devs to transfer this knowledge on the job. Even so, there will be enough new programmers who don't know this, and enough companies who eschew senior talent as a cost-savings measure, that this vulnerability will continue to rear its ugly head.
So, Bobby Tables will have his name tattooed on his face...
Sleep your way to a whiter smile...date a dentist!
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
And also too easy to do it right.
It doesn't have to be like this. All we need to do is make sure we keep talking.
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.
Myself, I prefer to use stored procedures for all db interactions, and set table access to deny for the account used by the web server. But that's me.
-1 Uncomfortable Truth
No, I didn't write "a lack of people who write code". I exactly mean what I wrote: A lack of programmers.
What we have today is a load of people who learned programming somehow, kinda-sorta, but without understanding just what they're doing. Now add how most of them gains information about how to do things. By looking it up on the internet. And taking the first solution that looks like it works.
Of course it's easier to simply concat strings than using prepared statements and parameters. It is simply more readily understandable and less convoluted for people who have little knowledge and less time to gain it. And they don't know anything about security and why this could possibly be a security problem.
These people are cheaper than people who know what they're doing. So much cheaper even that the additional time they need to get anything done is easily compensated. And whether it is a security problem is usually only found out after a security breach happens because, well, whoever hired them has even LESS knowledge about security.
And since every year a new batch of people comes out of schools that kinda-sorta learned how to kinda-sorta do queries, this problem will mean job security for me 'til retirement.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
So why, in 2015, is SQLi still leading to some of the biggest breaches around?"
Easy, idiots writing the apps because companies don't want to pay for skilled people that demand honest wages. they instead outsource ti for the lowest bidder and then bitch when they get crap quality because that is all they were willing to pay for.
Do not look at laser with remaining good eye.
There simply isn't any incentive for to build software that will last through some cyber attack some 10 months or 3 years into the future. The current incentives reward sloppily slapping together something that barely functions and gives a demo without crashing. If your demo crashes and makes the boss look bad, you're fired. If your demo works, has slick graphics and no spelling mistakes and the english dialog is polished, you get a raise. You're building software for the boss's demo, you're not building software that's robust, handles edge-cases, and input sanitizes everything. I meant, you could, but you're not getting paid any extra for it.
There's a lot more client/server going on, and a lot of programmers haven't discovered that you can't trust the client and are doing all their input validation and sanitation on the client side. As long as that's going on, this sort of attack is going to be popular. '); drop table articles.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I always wonder why people - even professionals (ableit only the non-DB pros) - think SQL is a feasible means for an application to utilise persistance. It isn't. In fact, it's a huge smelly turd for app-persistance and using it so broadly for this sort of work is a really harebrained and abysmally stupid idea.
That we have to deal with SQL injection problems is one of the countless pieces of crap based on this technology decision.
SQL was meant as an end-user interface for interacting with relational database - and for that it is absolutely perfect. End of story.
Using SQL as intermediate for application persistance is one of the most annoying and studidest things in the history of applikation development - for reasons to countless to list them. DB designers are among those who time and time again shake their heads in disbelief when they see the mess devs do with SQL.
We suffer more in our imagination than in reality. - Seneca