SQL Injection: bypassing addslashes()

Filed under Fu (a.k.a Tips), Web Hacking

This is really simple. Many will try to nullify SQL injection using the php addslahes() function. However, this is easily bypassed using an invalid multi-byte character. Let me illustrate how this works:

Entering the hex value: 0xbf27 (invalid)

MySQL will mutate it into something valid: 0xbf5c27

when looking at this mutated result in ascii, it looks like: ¿\’

The issue exists at the hex level. the 0xbf5c is read as a single character, leaving the 0x27 by itself. That means that although there is a preceding slash, it is not registering it as such, and leaves the inverted comma unescaped, and successfully injected past addslahes().

Read more in detail here:

Hackipedia – SQL Injection

ZeroIdentity: “addslashes() exploited?”


  1. Parvesh Garg says:

    I normally use mysql_real_escape_string() with mysql to prevent injections. Believe its safer option than addslashes().

    Have you encountered any problems with that?

    • Skyler says:

      Supposedly you can bypass mysql_real_escape_string() by taking your injection string in UTF-8, and converting it to BIG-5; however this only would work in certain scenarios depending on the PHP code. I have never done this, so I cant say for sure if it is possible. There are probably other ways out there. I personally would use mysql_real_escape_string combined with prepared statements and bound variables. That would seem pretty secure to me.

  2. Reiners says:

    published 2007: http://kuza55.blogspot.com/2007/06/mysql-injection-encoding-attacks.html
    addslashes() does not affect the multibyte character but MySQL does if the character set is configured/changed to a set listed in kuza’s blogpost.

  3. It’s not really that simple.

    I first saw that very exact example a year ago (it was in a quiz from a security course). It requires that your database is configured to use that charset. I believe that most databases in the western world are not configured to use that charset, thus the attack won’t work.

    Even though you should use prepared statements to prevent SQLi, mysql_real_escape_string() will prevent the attack. The difference between addslashes() and mysql_real_escape_string() is that the latter is aware of the charset used in the database (it connects to the database to retrieve that information).

Post a Comment

You must be logged in to post a comment.

Read previous post:
Stuxnet RE code on GitHub

Thats right, the code that was reverse engineered/decompiled from Stuxnet is now on GitHub. Here is the link: https://github.com/Laurelai/decompile-dump