Bypassing PHP security (addslashes) while SQL injection attacks is possible

Bypassing PHP security (addslashes) while SQL injection attacks is possible

Bypassing PHP security (addslashes) while SQL injection attacks is possible

Hello Again, Here I completed this article.. I apologize because I took bit more time to complete this after announcing. As I said before some days that many developers recommends some PHP functions to secure their web application to prevent SQL injection attacks. but unfortunately attackers can bypass such security measures and break into the system. Lets check how they do that with some examples.

First of all lets check


string addslashes (string $str)

It is widely used to Return a string with backslashes before characters that need to be quoted in database queries.These characters are single quote (‘), double quote (“), backslash (\) and NUL (the NULL byte).

  • The will becomes \’
  • don’t will become don\’t
  • ‘ OR ‘1’ = ‘1 will become \’ OR \’1\’ = \’1

In a single-byte character set, the string \’ is seen by MySQL as 0x5c 0x27

i.e. \  –> 0 1 0 1 1 1 0 0  AND –> 0 0 1 0 0 1 1 1

In the multibyte character set Big5, one byte is used for ASCII and two bytes are used for Big5 characters. Sometimes there is a twist when a MySQL database, table, or column uses a multibyte character set…

If a Big5 character exists with the last byte 0x5c (value for backslash), we can trick addslashes into forming the two-byte Big5 character when it inserts the backslash (0x5c)

For example consider a string with two characters: 0xbf 0x27

¿ —> 1 0 1 1 1 1 1 1

—> 0 0 1 0 0 1 1 1

When that string is passed through addslashes, a backslash is inserted: 0xbf 0x5c 0x27

¿ —> 1 0 1 1 1 1 1 1

\ —> 0 1 0 1 1 1 0 0

—> 0 0 1 0 0 1 1 1

MySQL with the Big5 character set then interprets this string as:  0xbf5c 0x27

縗  —> 1 0 1 1 1 1 1 1 0 1 0 1 1 1 0 0

—> 0 0 1 0 0 1 1 1

Note that the apostrophe is not escaped when processed by MySQL, and will now act as a delimiter which allows us to inject our SQL.

This works for two reasons:

  1. The value 0xbf5c is a valid two-byte character in Big5.
  2. addslashes does not check the MySQL character set.

Therefore, some multibyte character sets allow for a targeted attack on addslashes that results in successful SQL injection.

Any multibyte character set with value of 0x5c in the last byte of a valid character was vulnerable. Vulnerable sets included Big5, GBK, and SJIS among others This problem was fixed in MySQL in 2006. But Hackers can still exploit attacking ways by using such character sets.

In upcomming article lets see how mysql_escape_string can be bypassed.