Então, o que fica de aprendizado nisso é que o prepared statement, mesmo na emulação do PDO, faz sim o papel de evitar que o atacante "saia das aspas" da concatenação. Contudo, como pode ser visto nesse cenário, essa proteção falha quando temos um código que mistura a construção dinâmica de uma parte da query (como o nome da coluna) com o uso de parâmetros seguros, e o atacante usa um null byte para enganar o próprio analisador (parser) do PDO, convencendo-o a mover o ponto seguro da injeção para um local totalmente vulnerável.

Zeroc00i News & Tricks

Você usa um código PDO parecido com este? $col = $_GET['col']; // A variável é controlada pelo usuário $stmt = $pdo->prepare("SELECT `$col` FROM fruit WHERE name = ?"); $stmt->execute([$_GET['name']]); Caso sim, considere desabilitar a funcionalidade de…

Então, o que fica de aprendizado nisso é que o prepared statement, mesmo na emulação do PDO, faz sim o papel de evitar que o atacante "saia das aspas" da concatenação.

Contudo, como pode ser visto nesse cenário, essa proteção falha quando temos um código que mistura a construção dinâmica de uma parte da query (como o nome da coluna) com o uso de parâmetros seguros, e o atacante usa um null byte para enganar o próprio analisador (parser) do PDO, convencendo-o a mover o ponto seguro da injeção para um local totalmente vulnerável.