Why is this prone to SQL Injection?

Question

I've been reading this and when reaching the part of addslashes mitigation I came across this:

$id = addslashes( $_GET['id'] );
$query = 'SELECT username FROM users WHERE id = ' . $id;

Saying it's vulnerable to SQL Injection but not this:

$uname = addslashes( $_GET['id'] );
$query = 'SELECT username FROM users WHERE id = "' . $uname . '"';

How is the first vulnerable and why?

This comes when I'm looking at some old code that uses this syntax:

$query = "SELECT * FROM users WHERE user='$user' AND password='$password'";

The variables are addslashed before using them, but still I've been told this is vulnerable. I know the right practices call for PDO this days, but it just caught me cold when I couldn't explain to myself how this would be vulnerable.

Can somebody give me some example in where it could be bypassed addslashes? Besides GBK charset

EDIT: After reading the reply post, I perhaps need to clarify: The idea is getting to know what values could trigger the problems, and why, not how to avoid it as I'm already using PDO in the testbed, but want to learn from old mistakes as well and in-depth.

possible duplicate of [How can I prevent SQL-injection in PHP?](http://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php) — Darragh Enright, Aug 19 '15 at 10:01
This previous question has answers that explain this better than I can - http://stackoverflow.com/questions/860954/examples-of-sql-injections-through-addslashes . Essentially the difference between your first 2 code snippits is the first is using the value as a number (hence escaping values that would terminate the string is not useful when it isn't used as a string), while the 2nd is using the value as a string (which can usefully be escaped). Your 3rd snippit should be relatively secure, but is vulnerable to issues with addslashes and various character encodings. — Kickstart, Aug 19 '15 at 10:23
@Kickstart, great! Thanks for the link. I've tried to use the same technique with cURL with the third snippet (again, only thing touched from the $user and $password values is they're addslash-ed beforehand) but I don't get the behaviour it's described. Perhaps it depends on certain version of PHP? — Debianita, Aug 19 '15 at 10:43
Your 3rd snippit should be relatively safe (while still possibly insecure, sql injection on it is non trivial) as the user id and password are both in quotes. — Kickstart, Aug 19 '15 at 11:06

score 3 · Answer 1 · edited Sep 19 '16 at 07:06

The first SQL statement,

'SELECT username FROM users WHERE id = ' . $id;

is prone to = based or always true SQL injection. Like appending OR 1=1, which is always true, and, hence, returns all the rows from the users table.

Moreover, one can append the Batch of malicious SQL statement.

Check this out: SQL Injection

The second query is a little safer, but that doesn't mean it is safe from SQL injection.

Why is this prone to SQL Injection?

1 Answers1