Slashdot Mirror
How Prevalent Are SQL Injection Vulnerabilities?
Krishna Dagli writes to tell us of an investigation, by Michael Sutton, attempting to get an estimate of how widespread SQL-injection vulnerabilities are among Web sites. Sutton made clever use of the Google API to turn up candidate vulnerable sites. You might quibble with his methodology (some posters on the blog site do), but he found that around 11% of sites are potentially vulnerable to SQL injection attacks. He believes the causes for this somewhat alarming situation include development texts that teach programmers insecure SQL syntax, and point-and-click tools that allow the untrained to put up database-backed sites.
This is a possibility that was obvious back when I was developing web applications as far back as 1996 using CGI. The approach in TFA was a similar approach we used "back when" to demonstrate the need for (a) not using GET, (b) turning off verbose error reporting, (c) controlling *how* queries were made (e.g. architecture of the app and DB I/O), and (d) storing sensitive data encrypted. The sad part is that it is *still* a problem. I guess it underscores the need for a decent architect as opposed to letting whiz-bang do-it-yourselfers start coding without design, and the need for security analysis, et. Al. Just my 2 cents.
The simple solution is to use parameterized queries. I don't know why more books don't know why more books don't push this methodology, as it makes you program faster, easier to read, and also makes you invulnerable to SQL injection attacks.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Won't work. The same 'novices' who leave gaping SQL injection holes will now be writing pages that need to access the file system. Now instead of accessing the DB, script kiddies will be traversing the filesystem. Yes, this can be mitigated through file permissions, but there are a lot of servers out there (set up by these same novices) where processes run as root and would have full access to read and write files. So, a bad script could allow them to write to /etc/passwd and have all sorts of fun.
Stupid application construction isn't a good reason to make the design of the app even stupider.
In the old days, everyone used flat files, because that's what there was. Then someone (several someones, most notably Codd and some others at IBM) realized that breaking the flat data into sets of discrete data that related to each other reduced redundancy and allowed for an overall better quality of data. And it wasn't app specific.
The answer to SQL injection is to test apps more completely (including tests for this kind of attack), to provide extra checks at the database level (for integrity issues, perhaps in the form of constraints, etc. dependent on the scale and structure of the database), and to develop tools/libraries for data access that make this kind of thing hard to do accidently.
Why convert to an entirely different structure when just implimenting proper code standards will suffice? Using parameterized stored procedure calls instead of dynamic SQL will not only protect you from the vast majority of SQL Injection attacks, but will also improve the performance of your web page.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
In short, trusting the client (i.e. the web browser) to not send bad values - either through the INPUT tag's maxlength attribute, JavaScript scrubbing or whatever - is entirely the wrong way to go. The web script must check all user input for validity along with properly escaping everything from the database that's getting sent back via HTML.
Ita erat quando hic adveni.
Hello? Has the Net gotten so crime-ridden that instead of blaming criminals for doing illegal things, that we're now blaming developers? I mean, sure developers need to do all they can, but at what point do we, as a society say, "Hey, let's prosecute some of these assholes that are making life online a royal pain in the ass?" It's pretty absurd that today, you can still do whatever you'd like online (hack sites, networks, steal information), and there are really no repurcussions. We see what, one person getting jail time every 6 months? That's fucking insane. It's time for our government's law enforcement to step up to the plate, learn what the fuck a mouse is, and start prosecuting some of these people. Email is already useless. The web is getting there pretty quickly. SQL injection, firewalls, blah, blah blah.
If I have somebody who is constantly trying to break into my house, to the extent that I have to pay a security professional just to keep them bastards out, I'd be down at the police station talking to the police chief, angry as hell. As is, people have come to accept that there's almost more crime than legitimate traffic on the Net these days. That's insane. Something has to be done about this mess before the entire Net is just useless.
This 11% was determine by a weak testing mechanism. For every site that baltently spews sql errors to the user there are two that silently return a generic sanitized error, and another two that return no error at all. It would produce more results if you take it a step further and ask yes no questions, such as:
?id=99999' OR '10
and see if the page returns the results of id=10 as expected. It's also common for people to use weak regexp (regexp should NEVER be used to protect against sql injection, see mysql_real_escape_string) and miss some characters:
?id=99999)
or fail to sanitize non us language encoding. Also, get variables are often the most protected. It is much more common to find sql injection in <input type=hidden variables, or in cookie data. The number 11% is extremely low. I'd guess more like 80%.
From the article:
...
* Many development texts actually teach programmers insecure SQL syntax.
* Many sites are exposed to SQL injection attacks but don't know it.
I agree completely! I've seen the texts, I've seen the hordes of VB+SQL programmers that learned from said texts moving to the web porting the same "vices" to the new platform.
And I've seen the "oh-sh*t" face on a couple of developers after demonstrating to them that their software is vulnerable to SQL Injection. In both cases the vulnerabilities exposed the customers to the posibility of serious financial damage.
So far, the stupidest work arounds i've seen have been:
Developer: It's ok, I'll switch to post instead of get so the user can't forge the request.
Developer: It's ok, I'll write a method that removes sinlge quotes for every string i get from the user.
Developer: It's ok, I'll write some java script that will validate user input.
Writing secure software is never easy.
moi
Yeah, but most people are still stupid and humorless. So, in the end, I come out ahead.
If anything, I'd question how FEW sites they claim are vulnerable to SQL injection. It's an insidious problem that just creeps up on you anytime you don't think about it sufficiently (as when writing something quickly, on a deadline... not that this ever happens!). I know that at my workplace we fell victim at one point to a SQL injection attack on one of our (many) custom PHP scripts. We eventually found out how it worked through the web logs and were able to fix it, but honestly even after we did our best to clean things up... I'm dead certain that there are still probably hundreds of places that we're still vulnerable. This is due to a number things including the sheer volume of PHP code in use, the fact that the code has been written at various points in time over a period of six years or so, and the fact that this code has been written by at least twenty different people. It's like trying to plug holes in a dam.
As some others have pointed out, there are tools to get around that sort of thing. You should be validating all input server side, whether it's validated client side or not. There are also very easy ways to deal with SQL injection already, such as parameterized stored procedures. Doing what you suggest would involve a hell of a lot of recoding, break a hell of a lot of existing sites, and proceed to punish good coders by making them work around the "safe-guard". Programmers who don't take steps to protect against SQL injection deserve to have their sites hacked. And guess what? If they have their sites hacked, they'll probably remember to do something about it in the future, or hire someone who already knows how.
I may sound like an elitist by saying the following, but secure programming should not be "easy" for the "masses". It should be reserved for those who know what the hell they're doing, and they should be paid accordingly. I do not believe it's wise to give the average Joe the tools to make even slightly sophisticated programs. We've seen what happens when we do this; take a look at most websites from the dotcom bubble.
Everything I say is a lie. Except that... and that... and that, and that, and that, and that... and that.
All the HTML standards in the world won't stop an attacker with a copy of telnet.
/vulnerable_app.php?id=%2310 HTTP/1.1
bash$ telnet example.com 80
GET
Two things to note here: (1) there's no HTML involved in the actual transaction at all (2) like another poster said: you can't trust the client to send valid data.
Stick to purposing solutions for things you know about.
Why are the point and click or turn key solutions so vulnerable to SQL injection in the first place? I had a friend with a PHPBB site that got shot to all hell when some cracker came along and defaced it. Why wasn't it secure out of the box? Second of all, why is it that every website has to worry so much about security. I know about databases but I don't know the first thing about preventing an SQL injection attack and why should I have to. There is nothing sensative on my sites. Let me throw out this analogy.
Let's say I own a house and around Christmas time I put out an inflatable snow man. Then some vandals come along and pop it. Are you going to walk up to me while I'm sulking over my snow man and say "Don't you know you have to wrap your snow man in kevlar to prevent vandalism and then put up an electified fence with constantine wire on it."? I would give you the strangest look if you did. Then I'd probably say something pertaining to the fact that the police should catch these bastards and presecute them.
So why is it with technology that no emphasis is put on catching vandals and bringing them to justice and a ton of emphasis is put on protecting your site from attack?
The trick to exploiting SQL injection is being able to figure out the right sequence of input characters needed to gracefully terminate the intended SQL command, while also being able to craft a subsequent SQL query that does what you intend. Alternatively, you may want to modify the intended command. For example, "SELECT orderstatus FROM table where orderid = $FORM{'orderid'}" expects the orderid form field to be some value that's in the table somewhere. If instead you enter "1 OR 1=1" as your input, you'd get every row back since 1=1 for all rows. Using this example, you could also try to append a new query, by entering something like "1; drop database;". Many times an attacker will need to find various escape characters, quotes, etc. to get their input crafted properly to exploit the app.
SQL errors in web apps are what web crackers like to see for the same reason that exploit authors like to see segfaults where EIP=0x41414141.. it means that they were able to get their input down to the execution point in a program that got past the boilerplate protections that the app had in place (if any).