[SQLi] So you thought your login system was secure?

RogueCoder · 02-22-2014, 07:29 PM

Often developers things that as long as they don't check for a valid password in the query, but does it in the code instead, it cannot be bypassed with sql injection. This together with poor hashing like md5 is super simple to bypass if you can injection union.. In this post I will explain why..

First let's look at how many processes the username. We do some simple sanitation by stripping all spaces. This should be secure enough right? Meh, not really

Code:
$username = str_replace(' ', '', $_POST['username']);
$query = "SELECT * FROM users WHERE username = '{$username}'";
/* Execute the query here and fetch data to $row */

This is easily bypassed using alternative white spaces or comments

Next we look at the password check.

Code:
if ($row['password'] !== md5($_POST['password'])) {
// Login failed! Report this to the user
} else {
// Login was successful! Proceed to user account
}

So this is pretty secure right? Because you cannot inject and the code is actually checking this content for you, so the sql injection alone is not validating.. Or is it? Let's look at what happens

1) You enter your username and password in the form
2) The query locates the record containing the decired username
3) The query returns the content of the columns in the record
4) The code checks to see if the password that was stored matches the one that the the user entered

So this should be rock solid.. But you should think again.. Let's see what we can do to bypass this
(The example is using 3 columns. 1) id 2) username 3) password)

Username: ' UNION SELECT null,'admin',MD5('bypassed')-- -
Password: bypassed

So what happens here?

This result will return 1 row only, and the reason for this is because there's no user without a username. So instead it will be using the crafted credentials that we added in the union select payload. And we then added a unhashed version of the password "bypassed" in the password field.

This means that the query will return the username "admin" and the password will be a hashed version of the word "bypassed". Now when the code validates the password it hashes it with md5 and validates as an existing account..

This was a quick run down on how to bypass these types of scenarios Smile

RogueCoder · 02-22-2014, 07:29 PM

Often developers things that as long as they don't check for a valid password in the query, but does it in the code instead, it cannot be bypassed with sql injection. This together with poor hashing like md5 is super simple to bypass if you can injection union.. In this post I will explain why..

First let's look at how many processes the username. We do some simple sanitation by stripping all spaces. This should be secure enough right? Meh, not really

Code:
$username = str_replace(' ', '', $_POST['username']);
$query = "SELECT * FROM users WHERE username = '{$username}'";
/* Execute the query here and fetch data to $row */

This is easily bypassed using alternative white spaces or comments

Next we look at the password check.

Code:
if ($row['password'] !== md5($_POST['password'])) {
// Login failed! Report this to the user
} else {
// Login was successful! Proceed to user account
}

So this is pretty secure right? Because you cannot inject and the code is actually checking this content for you, so the sql injection alone is not validating.. Or is it? Let's look at what happens

1) You enter your username and password in the form
2) The query locates the record containing the decired username
3) The query returns the content of the columns in the record
4) The code checks to see if the password that was stored matches the one that the the user entered

So this should be rock solid.. But you should think again.. Let's see what we can do to bypass this
(The example is using 3 columns. 1) id 2) username 3) password)

Username: ' UNION SELECT null,'admin',MD5('bypassed')-- -
Password: bypassed

So what happens here?

This result will return 1 row only, and the reason for this is because there's no user without a username. So instead it will be using the crafted credentials that we added in the union select payload. And we then added a unhashed version of the password "bypassed" in the password field.

This means that the query will return the username "admin" and the password will be a hashed version of the word "bypassed". Now when the code validates the password it hashes it with md5 and validates as an existing account..

This was a quick run down on how to bypass these types of scenarios Smile

Ligeti · 02-22-2014, 10:17 PM

You know so much about SQLi that I sometimes wonder... do you ever sleep? lol

Remember when I asked you about PHP magic quote? well...

Quote:... So why did this feature exist? Simple, to help prevent SQL Injection. Today developers are better aware of security and end up using database specific escaping mechanisms and/or prepared statements instead of relying upon features like magical quotes.

Source: http://www.php.net/manual/en/security.ma...es.why.php

Interesting... anyway!

Thanks again, I can't wait for the eBook Smile

Ligeti · 02-22-2014, 10:17 PM

You know so much about SQLi that I sometimes wonder... do you ever sleep? lol

Remember when I asked you about PHP magic quote? well...

Quote:... So why did this feature exist? Simple, to help prevent SQL Injection. Today developers are better aware of security and end up using database specific escaping mechanisms and/or prepared statements instead of relying upon features like magical quotes.

Source: http://www.php.net/manual/en/security.ma...es.why.php

Interesting... anyway!

Thanks again, I can't wait for the eBook Smile

RogueCoder · 02-22-2014, 11:28 PM

(02-22-2014, 10:17 PM)Ligeti Wrote: You know so much about SQLi that I sometimes wonder... do you ever sleep? lol

Lol fair question Biggrin

I guess I could get some more sleep, but ain't got no time for that Tongue

(02-22-2014, 10:17 PM)Ligeti Wrote: Remember when I asked you about PHP magic quote? well...

Quote:... So why did this feature exist? Simple, to help prevent SQL Injection. Today developers are better aware of security and end up using database specific escaping mechanisms and/or prepared statements instead of relying upon features like magical quotes.

Source: http://www.php.net/manual/en/security.ma...es.why.php

Interesting... anyway!

Thanks again, I can't wait for the eBook

This is what the blog post I linked you to explains. Magic quotes is the same as addslashes and here's a quote from the post explaining how to bypass it.

Quote:In GBK, 0xbf27 is not a valid multi-byte character, but 0xbf5c is. Interpreted as single-byte characters, 0xbf27 is 0xbf (¿) followed by 0x27 ('), and 0xbf5c is 0xbf (¿) followed by 0x5c (\).

How does this help? If I want to attempt an SQL injection attack against a MySQL database, having single quotes escaped with a backslash is a bummer. If you're using addslashes(), however, I'm in luck. All I need to do is inject something like 0xbf27, and addslashes() modifies this to become 0xbf5c27, a valid multi-byte character followed by a single quote.

So what this sais is that when you're doing sql injections you can start your payload with ...

Code:
%bf%27 [payload_follows_here]

... which will bypass magic quotes / addslashes

Hope this answers your question Smile

RogueCoder · 02-22-2014, 11:28 PM