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

No this is still very relevant.

As are XSS and CSRF. Never underestimate the importance of proper input filtering.

Answer 2

As I've mentioned several times on stackoverflow before, I am a strong supporter of PDO, just stop using the old fashioned mysql, do yourself and your clients a big favor and learn PDO (it's really easy) and take advantage of prepared statements and bound parameters. Even if you do not need prepared statements performance wise, you still get the security benefits.

Also, I will recommend crashing your entire app in the clients face if magic quotes is set to on. It's just a drain on resources designed to protect the dumb and annoy the smart. (it uses more cpu than escaping manually, because it encodes everything, even when you don't need it)

Answer 3

There are a lot of different ways to perform a SQL Injection and quite a lot of ways to bypass basic safety precautions.

Those attacks have been within the top 10 web application vulnerabilities (rank #2) according to OWASP.

For more information, please refer to Top 10 2007-Injection Flaws.

Answer 4

This is very much an active risk, magic quotes tries to give you a solution but I prefer to always develop with magic quotes off. This way I have to make sure I actually escape the inputs myself. Who knows if magic quotes will be on or off on the server where the script is actually deployed.

Answer 5

That particular attack doesn't work, as mysql_query will only execute a single statement.

I can still abuse your code though, e.g. if I arranged for id to be SELECT password FROM Users WHERE Username='admin' I might have a fighting chance of being able to get your system to expose some internal information.

Basically, if you allow unfiltered input into your SQL, there will be some very creative ways of both creating data you didn't expect, and exposing data you didn't intend!

Answer 6

The simplest rule of thumb is to assume that all user input can be tainted. Check that data types are what you expect, variables are in the length/size ranges you were expecting, files are of the size and types you allow, etc. Other checks on non-external data can be warranted - before you call some important admin-level function, do a check - ($userlevel != ADMIN)?die():important_function();

There's always a bigger fish, or somebody who's a bigger jerk than you. Avoid assumptions about data and you've got a head start.