Can addslashes be bypassed when using utf and single quotes?

Question

I am trying to verify if using addslashes on a script is exploitable or not, it's known for everyone that addslashes shouldn't be used but, but the question is, is it always exploitable?

I found plenty of information on abusing addslashes in two cases when the charset is NOT utf8 (using double byte conversions) and also when the variable is enclosed by ""

So, can addslashes be bypassed when none of those cases above happens? This is the code I've been testing with:

data.sql file with the db dump:

CREATE TABLE IF NOT EXISTS `test` (
  `user` varchar(25) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

INSERT INTO `test` (`user`) VALUES
('admin'),
('user');

mysql -u test -ptestpw test < data.sql

index.php to place in the server

<?php
  //Server script the receives content via post
  mysql_connect("localhost","test","testpw");
  mysql_select_db("test");
  $user=addslashes($_POST['username']);
  $query="SELECT * FROM test WHERE user='".$user."'";
  $q=mysql_query($query) or die (mysql_error());
  $num_rows = mysql_num_rows($q);
  echo "Listed rows: $num_rows";
  if ($num_rows > 0) {
        $a=mysql_fetch_array($q);
        print_r($a);
  }
?>

query.php to be placed on the client machine

<?php
//Client script crafting the special url
$url     = "http://example.com/index.php";
$ch      = curl_init();
curl_setopt( $ch, CURLOPT_URL,            $url     );
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 );
?>

Some references:

here (bypass using multibye string, non-utf db)
here (bypass using multibyte string, non-utf db)
here (bypass using var enclosed by "")

`everyone is telling that addslashes shouldn't be used, and I agree` well why are you persistent on using it? You need to use prepared querys using PDO, mysqli or at least `mysql_real_escape_string()` to protect your query from borking **NOT** `add_slashes()` — Lawrence Cherone, May 15 '13 at 12:43
Changing an existant codebase might be a huge task, specially changing the data model, so it's relevant to know about practical implications of this. Of course any new development should be done in other ways — aseques, May 16 '13 at 08:05

score 5 · Answer 1 · answered May 15 '13 at 18:09

addslashes escapes the bytes 0x00 (NUL byte), 0x22 ("), 0x27 ('), and 0x5c (\) by prepending a \ to it. There are documented cases where addslashes fails with the character encoding GBK on MySQL:

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.

And there you already have the answer: Since UTF-8 does not have valid encodings that end with 0x5c, it is not vulnerable to this attack.

However, since your script seems to rely on magic_quotes_gpc being enabled, which has been deprecated as of PHP 5.3.0 and removed as of PHP 5.4.0, your script is vulnerable in environments where magic_quotes_gpc is either disabled or not available.

You're right, it seems I posted the wrong version of the script, now it's fixed, the important part was the "$user=addslashes($_POST['username']);" That's the part I am trying to see if it can be bypassed, this doesn't depent don the use of magic_quotes_gpc that I already don't use — aseques, May 16 '13 at 08:16

Can addslashes be bypassed when using utf and single quotes?

1 Answers1