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.
How does not using GET stop anything, you can POST anything you want to a webserver just like you can GET anything you want from a webserver. Only using POST will make things a little harder, but it doesn't stop anything.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
I don't think you understand SQL Injection at all.
:)
If the obvious fix is to exclude special characters from password fields
It's not. First of all, it wouldn't work. Second, it makes to sense at all at any level. Sorry if I seem rude.
There are a lot of new programmers (or whatever we're calling people who make websites these days), who are not naturally paranoid and sensitive to the exploitation of their code. They shouldn't need to be.
I agree, but it's a dreamworld. I shouldn't need to fiddle with keys or whatever every time I use my car or get home. But I do.
Luckily you can create pretty safe code by making nice code. It's amazing how many side-effects "nice" has. But yes, you'd need to be a good programmer to make nice code.
> Writing secure software is never easy.
m primise_my_database(), you should be using tools that make it impossible to inject SQL.
:)... but both Ruby and Perl are MUCH better choices than PHP.
It's easy if you use good tools. PHP is not a good tool. Rather than hacks like mysql_replace_the_string_with_things_that_wont_co
Some ideas:
Perl's DBI, whose docs tell you to ALWAYS write SQL like:
$sth = $dbh->preprare('SELECT foo,bar FROM baz WHERE something=? AND another = ?')
$sth->execute(q{''Some\ things"'}, 10);
Notice that the programmer can't forget to escape the SQL -- because there's no escaping.
Even better is something like DBIx::Class, which lets you write
$resultset = $table->search({something => q{''Some\ things"'}, another => 10});
Again, no opportunity for the programmer to fuck up the SQL in any way. It's just like getting data out of the hash... DBIx::Class will generate the SQL (for any backend), run the query, stream in the results as needed, etc. It's easier and it's better!
Ruby on Rail's ActiveRecord is similar, but it's impossible to do certain types of joins. DBIx::Class is better in this regard. (And Perl is faster than Rails, and Catalyst is more complete rhan Rails
PHP makes it easy to write insecure code. Perl makes it hard! (With taint mode, a selection of ORMs, 10000+ well-tested modules, and nicities like Moose, Moose::Autobox, etc.)
My other car is first.
That, and/or bind, bind, bind. Concatenating user input into your SQL statements is bad on both security and performance.
Even if they did prosecute, it does you know good once they'd messed with your database or otherwise hacked you.
It isn't hard to secure an online application against SQL injection. So there's no excuses for the developer to write 'SELECT blah FROM table WHERE field='$forminput';' directly in their code is there?
Your example should be about you going to the police station complaining because you don't have a lock on your door, not because you need a paid security guard.
Yes, I agree that hacking crimes should be punished more, but that doesn't absolve you of your responsibility to secure yourself and your property.
"SELECT `userID`,`user`, `password` FROM `table` WHERE `user` = 'trim($_POST['user'])'"
Ack! Nice demonstration of the code that is vulnerable to attacks!
My user id is '; drop database; --
I'm in my right mind and I have the answer to everything!
Perhaps it would be more appropriate to use an analogy of vandals mortaring your snowman. For, you see, the problem with the e-vandals is that they are not actually physically present when they attack your snowman. Yes, there is proof that they attacked you, but chances are that determining their physical location is hard. Sure, you could look at the trajectory of the incoming projectile, but even then you are having to do a lot of imprecise and possibly flawed work to find out just where these attacks are coming from.
Another analogy, regarding security, is that of the attractive and financially well-endowed woman walking in a dark alley in a bad part of town. Sure, she SHOULD be safe, because she is a human and everyone should have some sort of basic respect for the dignity and humanity of all other people. Why is it, then, that she should have mace or a gun in her handbag? Why does she need to take a precaution to mitigate actual harm to her person? Why should she avoid a part of town known as being dangerous?
Apply this to web development. Why should developers protect their code? Why should they take extra steps to secure their sites and servers? Quite simply, the internet is a bad part of town, and we need to make sure that we are not doing things that make us susceptible to attack.
Concertina wire is more likely to help than counting on the prosecution of attackers and vandals.
Well, I have verbose error messages turned on on my local dev server to make debugging easier, but we log all errors on the live site, returning an "oops! something went wrong" generic error to users. Verbose errors can give you a lot of information, depending on what the error is.
First of all, it's going to tell a hacker what kind of system you're using. They'll probably find out anyway if it isn't apparent, but who wants to give them any help along the way? And then it all depends on what the error is. If i'm making reads to the filesystem or requiring files and I screw up the path, verbose error reporting will spit that path out. Now the hacker knows what your file system looks like, and possibly what kind of system you're using. Also, while the hacker is busy trying out various methods to inject SQL, verbose errors may spit out the entire failed query, giving them full knowledge of how to edit it to make it work...
All around, it's just a very bad thing.
Repeat after me kids: "GET and POST are equally tamperable and equally (in)secure. The only thing they are not, is equally logged".
Prepared statements aren't there to guarantee that every datum you insert is the "correct" type for what you're trying to do. What they do is guarantee that nothing in your variables will be interpreted as part of the SQL command.
If I have "10; <naughty stuff>" in $numeric_var, it will attempt to insert (or select, or whatever) exactly that string, without interpreting it. The data may be useless, but it will not be executed.
I hope not, since mysql_escape_string() will also allow for SQL injection by not respecting the character set of the MySQL connection. The PHP Group, in all its brilliance, decided to add another function, which they named mysql_real_escape_string(), rather than simply fixing the first one. /me sighs
[insert witty comment here]