Estou trabalhando com o módulo arcpy da ESRI e preciso especificar uma WHEREcláusula como parâmetro para esta função . Como o resultado será eventualmente usado para recuperar dados do banco de dados, o texto da WHEREcláusula é passado diretamente para o banco de dados em algum momento, mas, infelizmente, o ESRI não me dá nenhuma opção para parametrizar a consulta. Como quero me proteger contra uma possível injeção de SQL, preciso encontrar algum meio alternativo de proteger meu banco de dados.
Uma opção que vem à mente é limitar a entrada e lançar um erro antes dessa chamada de função se ela não estiver em conformidade. No meu caso, os chamadores precisarão apenas de caracteres alfanuméricos ASCII. Nenhum outro tipo de caractere é permitido na coluna a ser usada para filtragem. Limitar o usuário a apenas caracteres alfanuméricos seria suficiente para impedir a injeção de SQL, especialmente porque o texto deve ser citado como uma string?
Se você realmente pode limitar a caracteres alfanuméricos, então sim, tudo bem, SE você estiver limitando a caracteres alfanuméricos ANSI. Em Unicode, como cada caractere tem mais de um byte, muitas representações de caracteres alfanuméricos são realmente inseguras e podem levar à injeção.
Você precisará limpar os dados do lado do servidor e garantir que a codificação seja segura. Eu sugiro que você dê uma olhada nas bibliotecas ESAPI da OWASP para saber como elas fazem isso (consulte a terceira seção nesta página ).
A maneira normal é garantir que as várias palavras-chave do SQL não sejam permitidas na string digitada pelo usuário. No entanto, existem muitos casos para verificar.
Citações podem ser evitadas por algo como isto:
Retorna admin e a técnica de adicionar caracteres dessa maneira pode ser usada em WHERE sem a necessidade de usar aspas.
Então, basicamente - você terá que criar sua consulta e, antes de enviá-la ao banco de dados, verifique se ela não está fazendo nada que você não deseja, comparando-a com as palavras-chave SQL, mas há um bom número de coisas checar. Portanto, certifique-se de que itens como select, exec (todas as variações), convert, union, drop, truncate e praticamente todas as palavras-chave perigosas em qualquer combinação de maiúsculas/minúsculas, assim por diante, não estejam na string do usuário. Também não deve ser permitido nenhum fluxo de bytes (números 0x) que possam ser convertidos para evitar muitas verificações de dicionário, especialmente se os comandos exec forem esquecidos do dicionário.
E se for um aplicativo da web, certifique-se de verificar este lado do servidor e não do lado do cliente.
É praticamente o melhor conselho que posso dar se você não puder usar parâmetros.
Se estiver usando o Oracle - e se você for capaz de executar instruções arbitrárias nele - então você pode primeiro limpar a entrada usando
dbms_assert.enquote_literal(pelo menos, é meu entendimento que isso garante que o literal seja citado corretamente - mesmo permitindo as aspas embutido em strings).Consulte http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_assert.htm para obter mais detalhes.