
Note that in latin1 and gbk, 0x27 on its own is a literal ' character. In gbk, that's an invalid multibyte character in latin1, it's the string ¿'. The payload we're going to use for this injection starts with the byte sequence 0xbf27. There is another way of doing it, but we'll get there soon enough. This sets the character set ON THE SERVER. Now, it's very important to note the use of SET NAMES here. As it turns out, there are 5 such encodings supported in MySQL 5.6 by default: big5, cp932, gb2312, gbk and sjis. 0x27 and to have some character whose final byte is an ASCII \ i.e. Selecting a Character Set $pdo->query('SET NAMES gbk') įor this attack to work, we need the encoding that the server's expecting on the connection both to encode ' as in ASCII i.e. In certain circumstances, that will return more than 1 row. $query = 'SELECT * FROM test WHERE name = ? LIMIT 1' So, let's start off by showing the attack. It's based off an attack demonstrated here.

I'm adapting this answer to talk about PDO.

The short answer is NO, PDO prepares will not defend you from all possible SQL-Injection attacks.
