The History of SQL Injection, the Hack That Will Never Go Away (vice.com) 193
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?"
Well, (Score:1)
HIV is easy to defend against. Relatively so, also, are things like malaria. Yet they still manage to kill millions. Why, in 2015? Also, is that more or less of a concern than SQL injection attacks?
Re: (Score:2)
We appreciate the sacrifices you made to slow the spread of HIV.
Everyone has to learn about it. (Score:2, Insightful)
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, tha
Re:Everyone has to learn about it. (Score:5, Interesting)
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.
Re:Everyone has to learn about it. (Score:5, Insightful)
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!
Re:Everyone has to learn about it. (Score:5, Insightful)
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.
Re: (Score:3)
This just in, cargo-cult programming causes security holes.
That's not really news, is it?
Re: (Score:3)
Damn you are right. I did the simple "mysql php tutorial", and except for the first hit (from W3Schools), ALL of them used the old, deprecated mysql_* functions and were wide open to SQL injection.
Is there something the programmer's community ought to do? What could we do?
Re:Everyone has to learn about it. (Score:5, Interesting)
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)
Re: (Score:2)
Nope, switching to mysqli will not magically fix sql injections. The functions mysqli_query, mysqli::query and even mysqli::prepare allow for idiots to create broken code. Only if programmers are forced to separate the query from the data, it will be fixed. But that will never happen.
Re: (Score:1)
This is a good point. There really is a lot of poor code out out there as examples, and basically no oversight for making sure it's *relevant*. On one hand, it's easy to assume that the crappy programmer who has to google up answers to his programming is to blame, but on the other hand this is very much a self-taught career/hobby for an absolute ton of people.
This is also a problem with many "updated" programming books. I picked a PHP guide the other day, revised in early 2014, and it mentions SQL inject
Re: (Score:1)
Talented programmers don't copy-paste code from search results. They do the search to learn the facts they are lacking, so they can code the solution themselves. The sort of person who can't think a problem through, and so routinely just googles a solution and uses it as-is, is precisely the sort of person who should not be programming for a living.
Sorry for being an elitist ass, but the job is hard, and not everybody is cut-out for it. Too much dependence on MSSQL by Danny Droptables is a clear sign that you belong in another industry.
There corrected the error of your logic.
Re: (Score:3)
That's what PHP frameworks are for. The main thing I look for in a framework is actually just a good DB interface. One that simplifies query construction and automatically escapes data. I've written some surprisingly complex queries using CodeIgniter's Active Database system (Laravel has a very good one too). About the only time I have to write SQL by string concatenation is when I do crazy subselects or unions.
I don't know why that functionality is bound up with frameworks. I think it's because PHP's manag
Re:Everyone has to learn about it. (Score:4, Interesting)
What's wrong with prepared statements?
http://php.net/manual/en/pdo.p... [php.net]
That last time I touched PHP, over 10 years ago, you could do this.
But then there was crap like this: http://php.net/manual/en/funct... [php.net] Perhaps they planned to make a mysql_fake_escape_string function but instead accidentally called it mysql_escape_string
Re: (Score:2)
For the simplest selects and inserts PHP could easily provide an interface that escapes the arguments. That would make it more natural for the lazy programmer to realize when he is doing queries that he has to think about.
If you're escaping your sql inputs you're part of the problem. SQL injection has been known to work on escaped strings using unicode tricks. Use bound parameters in parameterized queries and its not an issue at all.
Re: (Score:2)
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.
While I agree there is no excuse to allow SQL injection attacks, some frameworks have some really horrendous parameterized query syntax. I recently had to use the node-postgres client for the first time a few weeks ago, and I was running into some tough situations that took far too long to figure out. There were times I was tempted to not use parameterized queries, but ultimately I knew the dangers of doing it the easy way.
As long as the easy way to do things is not the same thing as the right way, these vu
Re:Everyone has to learn about it. (Score:5, Informative)
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.
Re: (Score:2)
It solves it in the sense that a procedure requires you pass inputs as query parameters.
No absolutely not. It does no such thing. Anyone can call stored procedures from strings without binding parameters. Using stored procedures in and of itself solves exactly nothing.
The types of people who still code in SQL injection attack vectors are the same types of people who aren't going to understand the subtleties of content versus context.
I'm sick of these lame ass excuses for ignorance. It isn't a hard concept at all in any shape or form to understand. Anyone who can't grasp it has no business in the industry.
Giving them a tool which will always force them to parameterize their queries is a means of saving them from themselves.
I worship at the church of designing systems requiring people to try really hard to fail yet this isn't what my comment is about. It is about "common
Re: (Score:2)
What I meant was that stored procedures can help keep strings of SQL out of your application code. Yet, you still need to be smart and use them as you would a parametrized query. That is, send the SP strongly typed parameters.
OWASP has this section about SQL injects and what bad vs. good code look like. They list the following as the top three "Def
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
There's a new found disdain for DBAs, because they "slow things down" by pointing out issues before they become issues. Instead, every half-assed "web developer" also thinks they're a DBA because "web scale" or some bullshit. I've always found it ironic that businesses who depend upon the integrity of their data are the first to eschew the services of a good DBA because "slow" or because "nosql". Then again, I've generally always worked with competent DBAs would who ask questions about my queries and hel
Re: (Score:1)
I just don't get how it happens (Score:4, Interesting)
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.
Re: (Score:2)
Except when it isn't. What's the source of that $name parameter to your function? Has it been sanitized in any way? I can imagine your interviewees taking a punt on what kind of idiot they are facing. (Looks like he was born in 1955 so the answer is probably x)
Re: (Score:1)
No. You are the reason that SQL injection still happens. It should be parameterized no matter what. It is a public method and as a developer you don't know where it is called from. Or where it will be called from in future iterations of your software. SQL string concatenation is inherently dangerous activity, an anti'pattern. If you absolutely must do it, then variables should be sanitized within the method that is concatenating the statement to avoid errors always.
Re: (Score:2)
It's not really an issue with prepared statements. Prepared statements are just a form of pre-compilation. You just want parameterized queries, which is sort of related (prepared statements are usually parameterized, but not always).
Prepared statements are usually slower than non-prepared statements (depends on environment, database, etc), so if it is a one-off query that won't be reused then typically you don't want to prepare it. For queries you are calling over and over, or are calling repeatedly, the
Re: (Score:2)
Sorry, that should have read prepared statements incur an initial overhead, so for one-off queries they are slower, but actually executing them is faster.
Re: (Score:1)
The problem is that "parameterized" SQL is static
You can use parmeterized inputs with dynamic SQL.
set @Qry = N'
SELECT *
FROM AdventureWorks2008R2.Production.Product AS p
WHERE p.Field1 = @Param1 '
if something2
@Qry = @Qry + ' and p.Field2 = @Param2'
if something3
@Qry = @Qry + ' and p.Field3 = @Param3'
EXECUTE sys.sp_executesql
@statement = @Qry,
@params = N'@Param1 integer, @Param2 integer, @Param3 integer',
@Param1 = @parameter1,
@Param2 = @parameter2,
@Param3 = @parameter3
Re: (Score:3)
I'm curious to know why a senior programmer was writing code to handle apostrophes in the first place when that is probably built-in to whatever library you use. I'm legitimately interested, if you wouldn't mind following-up with a reply at some point. The answer is probably to the heart of why SQL injection continues to be an issue.
Re:Everyone has to learn about it. (Score:5, Informative)
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.
Re: (Score:2)
Hmmm... then I reword my question: "I'm curious to know why a senior programmer was writing code to concatenate strings of SQL." Fortunately, you answered it already when you said "It's a natural way for someone who doesn't realize the risks to do it." That is probably the most common reason for SQL injection vulnerabilities. But that statement concerns me. I expect someone labeled "senior engineer" would already know about these risks. Exceptions might be someone with a very narrow but deep focus like
Re:Everyone has to learn about it. (Score:4, Insightful)
The problem is inherent in many systems so you will always make a mistake until the day that you put all your queries into stored procedures.
Treat the DB as a generic object pool of crap and it'll be that. Treat it like its a precious storage system with its own (customisable) API and you'll do far better.
But of course, slapping SQL together in the client and sending it to the DB to parse and execute is so much easier everyone does it.
Re: (Score:2)
Fresh crop of computer science graduates should be those from which this should never happen. They are newly trained, supposed to be security awared. Particularily if they have to deal with web sites programming. This is the lamest excuse. I can rather than that old programmers getting a new assignement with web programming will not know how to circumvent such a problem even if they have heard about it in the news. Employers are often trying to save a few bucks on training of old farts.
However, I believe th
Re: (Score:2)
Re: (Score:3)
What would be nice is if they learned about it before they develop habitual patterns for using a language/platform.
The problem is that people who teach n00bs want to give them the success experience of updating a database early on, before they've learned about prepared statements and (the much broader topic) of checking user input. If they'd just stop that then over the course of years the problem would become much smaller.
Re: (Score:2)
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.
It's not like they teach 'how to protect yourself from SQL injection' in school. In school, they teach people how to program in a clean room, where all data is 100% good and only one person at a time uses a system.
Well in Government.... (Score:1)
Re: (Score:2)
And in the private sector I've usually seen it accompanied by the boss saying "My friend/son/cousin knows this computer stuff. I'll get him to do it."
Re: (Score:2)
That's better, because nepotism is better than communism.
Some parts of the US like nepotism so much they choose their spouses that way.
Re: (Score:2)
Re: (Score:2)
PHP (Score:5, Interesting)
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 [freewebmasterhelp.com], 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.
Re: (Score:2)
Re:PHP (Score:5, Informative)
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.
Re: (Score:3, Informative)
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... [youtube.com] 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 [wikiquote.org]) thought the best way to design an API is to just expose PHP's internal libraries' headers to PHP
Re: (Score:1)
Thinking about this a bit more, I've come to the conclusion that the PHP devs may have been correct to add the mysql_real_escape_string function instead of changing mysql_escape_string to invoke MySQLs mysql_real_escape_string (although not necessarily using their crappy name for it).
There's actually a subtle difference in the expectations of the real_escape variant; it requires an active MySQL connection to be open in order to work, which the older escape function does not. It's not exactly common to tr
Re: (Score:2)
You forgot magic_quotes, lol.
Re: (Score:2)
Re:PHP (Score:4, Insightful)
“When you know exactly what the APIs are, you’ll spot the bugs very easily. In my mind, it is the same as any other job that requires diligence. Be careful. Humans learn from examples, and yet, in this software programming environment, the tremendous complexity breeds non-obvious mistakes, which we carry along with us, and copy into new chunks of code.
We’ve even found in man pages where functions were mis-described, and when we found those, lots of programmers had followed the instructions incorrectly”
Re: (Score:2)
Re: (Score:3, Interesting)
I think that you goading someone into hacking your websites and then claiming that they are secure when they can't is actually quite disingenuous here. To be perfectly honest, from your post history I believe you have some vested interest in this banshee framework you keep linking to.
I did actually have a quick look at your websites and they don't actually present a lot of attack surface to work with. The only user input that's used is some id parameters from what I can see. It's utterly trivial to secur
Re: (Score:2)
I absolutely WAS. Was a CMS. Much better now (Score:5, Informative)
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.
Re: (Score:2)
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.
The first sentence is correct. But PHP was written in C, and calling CGI.pm a templating system is pretty generous. :-)
That was a long time ago, of course.
Clearly. :-)
PHP.net says Perl & C in 1994. Text::Template, (Score:2)
PHP.net says "1994 - Started writing CGI scripts in C and Perl".
http://talks.php.net/show/comm... [php.net]
By the time PHP was gaining popularity, Text::Template and HTML::Embperl were available for Perl.
Rasmus's comments in this interview are revealing:
"I donâ(TM)t know how to stop it, there was never any intent to write a programming language [â¦] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the
way."
MP3 recording of these comments:
SQL Injection Trivial to Defend Against (Score:2)
...SQLi is relatively easy to defend against.
Relatively? It's trivial to defend against (spoiler: use prepared statements), and anyone creating software that has even the potential for SQL injection is an incompetent moron.
Hiring a programmer who doesn't know how to eliminate SQL injection is like hiring a surgeon who doesn't know how to use a scalpel, or a bridge builder who doesn't understand weight distribution. It's the first thing that a programmer should learn when learning to write database aware software.
Re: (Score:2)
Hiring a programmer who doesn't know how to eliminate SQL injection is like hiring a surgeon who doesn't know how to use a scalpel
I'd say it's like hiring a surgeon who doesn't wash their hands before operations. Even if they otherwise do a bang-up job, they could still screw things up.
[Though ... http://news.yahoo.com/clean-ha... [yahoo.com] ]
Re: (Score:2)
It can lead to bugs, depending on the interface.
A prepared statement like "insert into table (col_a, col_b, col_c, col_d) values (?,?,?,?)" makes it easy to mix up the parameters.
Not all prepared statement interfaces support named parameters. (I'm looking at you Java, that makes it even worse by starting the numbers at 1, contrary to just about every other Java API)
Webserver with ability to block SQL injection (Score:2)
The Hiawatha webserver can block SQL injection [hiawatha-webserver.org] attacks. I like to hear what you think of it.
Re: (Score:2)
The Hiawatha webserver can block SQL injection attacks. I like to hear what you think of it.
All heuristic attempts at blocking SQLi not only don't work but can themselves be leveraged as a vector for attack/denial.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Ah, so you'll only be vulnerable to SQL injection from the right IP address.
Grandparent post is correct. Do it right, and you don't need patches like this that could leave things uncovered or need clusmy unsafe patch-ups to try to cover up what you're doing wrong.
The attack that _would_ go away (Score:2)
If people used perl and DBI with properly prepared statements, instead of [censored] php.
Re: (Score:2)
I don't.
Re: (Score:2)
Plus, PHP was modelled after perl. The way one writes php to generate web pages is typically the way you do it just as well in perl (with the added bonus of clear separation of front- and backend code in perl).
Re: (Score:2)
Perl?!? Are you serious? That's the language you will have problems with to read back your own code after a minute you wrote it.
This is the same person who recently posted the following jem:
A language is not secure or unsecure. It's what developers do with it that makes the result secure or unsecure. I can write a .NET or Java application that has all the vulnerabilities you can think of.
Re: (Score:2)
The reason? A lack of programmers (Score:4, Interesting)
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.
Re: (Score:3)
Pay peanuts (Score:5, Insightful)
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.
Re: (Score:2)
Re: Pay peanuts (Score:2)
There are also many mistakes being made that demonstrate a basic lack of understanding, that cannot be attributed to lack of code review (my favourite example is email address validation code that assumes a TLD must have 2 or 3 characters).
Re: (Score:1)
Those who make the decisions often focus on superficial things. I don't know a fix for that.
I've seen people take sloppy shortcuts to put something visually snazzy up quick, and the clueless people who evaluate it think they are a Web-God.
If one points out potential security, ADA, performance, maintenance, device-dependent problems, they are painted as jealous nay-sayers. It's happened to me many times.
And those making the decisions expect to get promoted or hired away fairly soon; the long-term is not thei
Why? (Score:3)
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.
Well (Score:3)
Re: (Score:2)
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.
No they just hire the cheapest because they have no clue he/she is more or less competent than the more expensive candidates.
managers like to promote on 3wk projects (Score:4, Interesting)
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.
Legacy code (Score:2)
There is a ton of legacy code out there that was written before people worried about SQL injection. There's so much of it, going back and refactoring it would be as monumental as fixing the two-digit year problems of Y2K. Businesses really don't like to pay money for software development that doesn't lead to more sales, so it's a hard sell for IT departments. Sadly, this means that the problems don't get fixed until after a company loses money due to an actual attack.
Because we're not as "full stack" as we think (Score:2)
SQL has no place in applikation persistance. (Score:3)
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.
Re: (Score:2)
SQL was meant as an end-user interface for interacting with relational database - and for that it is absolutely perfect
That argument was lost decades ago, man. Turns out SQL wasn't that great for end-users, but programmers kind of liked it.
Re: (Score:2)
Thank you. I've been saying this for years. I'm glad someone else can see that the Emperor has no clothes.
SQL sucks. Not the concept of a relational database; that's something that's pretty cool. But the so-called "Structured Query Language" used to interact with the database is the worst affront to programming ever(*). It's not bad for user interaction, and I know it was an easy path to hacking in database support for languages that didn't have it. But for crying out loud, continuing to use it is just
Use JOOQ (Score:2)
MVProc (Score:1)
Re: (Score:2)
So, Bobby Tables will have his name tattooed on his face...
Re: (Score:1)
So, Bobby Tables will have his name tattooed on his face...
And his sister is still trapped in a drivers license factory...
https://xkcd.com/327/ [xkcd.com]
Re: (Score:3)
Re: (Score:2)
I wonder how Banshee compares to ProcessWire [slashdot.org]...
From the surface at least Banshee looks more "big-feature" complete|inclusive than ProcessWire.
Re: (Score:2)
Re: (Score:2, Informative)
Re: (Score:1)
There is no denying that PHP was made with design decisions that make it easy to write insecure code by default. PHP is less secure by default by itself for noobs and those far better than noobs. Look at FB's history with PHP. They created "Hack" to avoid many of PHPs problems, yet kept the good parts of PHP... noobs, hardly. Being 'popular' should have driven PHP to be secure, not used as an excuse for why it's easy to hack with SQLi.
Re: (Score:2)
Yeah, what is or could go wrong with that?
You tell us. Or maybe you don't actually know the answer, and just want to imply that you do.
Re: (Score:2)
There is no way around it.
What do you mean there's no way around it? That's the stupidest thing I've heard all day. It's simple to prevent even if you write all your queries with string concatenation. It's called an escape sequence.
Re: The problem STARTS with SQL itself. (Score:3)
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.
Re: (Score:2)
This is pretty much right. We're trapped writing snippets of one language (SQL) in another (PHP/whatever).
Avoiding any single SQLi vulnerability is trivial - use stored procs, escape strings, or use parameterized queries. You can even avoid most problems at the organizational level as long as someone competent is in charge and raw SQL is banned or forced into rigid guidelines.
But it seems we've collectively decided to trust our data interface to a framework that is at its core no better than an eval() in
Re: (Score:2)
var user={username:'bob',messages:[{username:'al',text:'hi bob!'}],contacts:[]}
When you realize how this can be translated exactly into SQL, you will be enlightened.
Re: (Score:2)
Re: (Score:2)
But MongoDB is web-scale.