Is SQL injection a risk today?

Question

I\'ve been reading about SQL injection attacks and how to avoid them, although I can never seem to make the \"awful\" examples given work, e.g. see this post

Answer 1

Heh, you're saved in this case by having magic_quotes_gpc set to "on".

You'll be screwed soon.

Answer 2

The largest identity-theft in history was achieved in 2007 by exploiting an SQL injection vulnerability: see "SQL injection attacks led to Heartland, Hannaford breaches" (ComputerWorld, 8/18/2009).

OWASP reported in 2007 that injection attacks (of which SQL injection is one example) continue to be one of the most common software security problems.

You can also search for recent SQL injection News and find many cases reported every month.

However, the example in the XKCD cartoon isn't necessarily the most common type of exploit. Dropping a table by executing a second SQL statement in one request probably wouldn't gain the attacker much in the way of valuable data, it would just be vandalism.

Also, some query interfaces disallow multi-query by default anyway. That is, the database client API executes only a single statement given the SQL string, regardless of semicolons. This defeats the example shown in the cartoon.

note: PDO's query() method is known to support multi-query by default. So it is susceptible to the XKCD-style attack.

As other folks have pointed out, the more likely risk is that an SQL injection will alter the logic of SQL expressions, and apply your query to extra rows besides those you intended.

For example:

$sql = "UPDATE Users SET PASSWORD = MD5('" . $_POST["password"] . "'||salt) " . 
       "WHERE user_id = " . $_POST["userid"];

What happens when I send a request with parameter userid set to the string 123 OR userid=456? I would reset my own password (userid 123) as well as the password of userid 456. Even hashing the password with a per-user salt wouldn't protect against this. Now I can log into either account.

There are lots of ways SQL injection can be perpetrated.

Answer 3

As per OWASP 2017 Top 10, still Injection is the most happened and dangerous attack.

"SQL injection is always the number one risk. That is a reflection of just how many incidents are out there, as well as other factors that keep it very high up there" Troy Hunt - founder of breach site haveibeenpwned.com

Just to remember, using SQL injection we can dump entire database, controlling web server by uploading web shell, etc.

Answer 4

No, and the less you worry about SQL Injection, the more likely you are to get hit by it.

Answer 5

Parameters passed to sql queries from the web pages ofen tend to be numeric IDs. For example let's assume you have an url http://foo.com/page.php?section=34 from which the section ID is used in a query like this:

SELECT content FROM sections WHERE section_id=$section;

No quotes to escape like in your example and whatever you'll put after the number in the URL will be passed to the query... So thew risk is real.

Answer 6

Oh my.. SQL Injection is not a risk, it is a gaping security hole. It mainly exists in php because the API makes you want to interpolate any old data into your SQL queries.

When I see a site written in PHP or ASP, I can just smell the SQL injection vectors that they reek of. People try to secure their PHP apps with mysql_real_escape_string() and intval() and do similarly in other languages. This is a mistake. It's like coding in C instead of Java or Python, where in the former, you make one mistake and you're dead, but in the latter, only semantic flaws can exist.

I strongly urge people to use either mysqli with prepared statements, or anything else that is parameterized, substituting text into code and then interpreting it is just bad practice in the first place IMHO.

On another note, PHP's magic quotes is just silly, and thankfully, deprecated. It can only cause more harm than good. If you rely on magic quotes, it means your app will be owned when magic quotes is disabled. Similarly, it may break other apps that don't expect escaped strings in inputs.