Proteção de injeção SQL: falácia de citações únicas Escape

No campo do desenvolvimento de software, a prevenção de ataques de injeção de SQL é crucial. Embora as consultas SQL parametrizadas sejam a melhor maneira de limpar as entradas, alguns desenvolvedores ainda usam o mecanismo de defesa que escapa de cotações únicas e envolve entradas do usuário em cotações únicas como alternativa.

Técnica de fuga falha

O método envolve a substituição de qualquer citações únicas na entrada do usuário por citações únicas duplas e envolvendo toda a string em citações únicas:

sSanitizedInput = "'" & Replace(sInput, "'", "''") & "'"

O princípio desta técnica é que quaisquer citações únicas inseridas pelo usuário são efetivamente neutralizadas para impedir que a string termine. Portanto, qualquer outro caractere, como um semicolon ou um sinal percentual, se torna parte da string e não é executado como um comando.

vulnerabilidade de injeção

]

No entanto, essa técnica não pode lidar com casos em que a entrada do usuário em si pode conter cotações únicas duplas. Nesse caso, a sequência será encerrada e o restante da entrada pode ser executado como comandos SQL.

Exemplo de entrada

Para ilustrar isso, considere a seguinte entrada do usuário:

'SensitiveData' HAVING AMOUNT>2000 OR ''=''

Após a execução, o código se tornará:

...

SELECT * FROM ACCOUNT WHERE NAME='SensitiveData' HAVING AMOUNT>2000 OR ''=''

Outras considerações

é importante observar que existem outras vulnerabilidades nesta técnica de fuga, incluindo:

não pode se defender de todos os tipos de ataques de injeção de SQL, como ataques usando comentários ou outros terminadores de declaração.

Introduzir sobrecarga de desempenho e manutenção.

• dificulta o código de ler e entender.
• Melhores práticas

!

use instruções de pré-preparação SQL ou JDBC parametrizadas.

somente os valores e formatos de entrada esperados (whitelists) são permitidos.

listas negras são usadas apenas se absolutamente necessário e depois que outras medidas de mitigação forem implementadas.

• Evite SQL dinâmico e concatenação de String.
• Considere o uso de procedimentos armazenados com permissões limitadas de banco de dados.