Cómo probar la consulta de inyección SQL

La forma en que planea usar la información es lo que mejor explica cómo manejar esto. Si intentas asegurarte de que nadie está usando un ataque de inyección SQL contra ti, la respuesta no es intentar detectarlo con listas negras. El enfoque adecuado es hacer uso de características como las variables de enlace.

Si su objetivo es proporcionar un sistema de advertencia para alguien que busca cosas que no deberían, la detección de palabras clave SQL como "and, or, select, delete, where, update, drop" puede ayudar. El problema con la lista negra ( saneamiento de consultas SQL (lista negra) ) es doble: es probable que obtenga falso positivos y probablemente te perderás los ataques bien ofuscados. Si bien puede darle una ventaja en la detección de ataques, he escrito consultas que van más allá de estos filtros y me siento muy frustrado cuando se bloquean las oraciones normales al rellenar formularios.

sqlmap lo hace fácil (agregue un * para cada posición de prueba):

sqlmap.py -v 4 -u http://example.com/category*/tutorials*/cooking*/
sqlmap.py -v 4 -u http://example.com/articles*/another-perspective-on-data*

-v 4 mostrará cada solicitud GET en la salida estándar para que pueda ver las solicitudes exactas y observar cómo se está explorando sqlmap.

Cuando una URL se ve así significa que está siendo reescrita. En un servidor web Apache se logra a través del archivo htaccess utilizando mod_rewrite.

Aquí hay un ejemplo de reescritura:

RewriteRule ^([a-z])-([0-9]).html$ /index.php?page=$1&id=$2 [L]

Se filtrarán todos los caracteres distintos de los definidos en la expresión regular. Se utiliza principalmente con consultas GET y proporciona cierta protección. Pero una expresión regular que no sea lo suficientemente específica podría permitir una inyección.

Aquí hay un ejemplo de reescritura vulnerable:

RewriteRule ^([a-z.*])-([0-9]).html$ /index.php?page=$1&id=$2 [L]

Las pruebas para una inyección SQL se verían así:

example.com/cate'gory/1234

Suponiendo que no existe ninguna otra forma de protección y que no se utilizan consultas parametrizadas ni se escapan correctamente las entradas, esa consulta le alertará sobre una posible inyección de SQL.

1) No puedes detectar de forma confiable un intento de ataque analizando estáticamente el texto de la solicitud.

2) Los controladores de solicitud escritos correctamente no tienen nada que temer de los ataques de inyección de SQL.

Puedo ver dos cosas que podrías estar intentando hacer.

Quizás desee identificar solicitudes maliciosas para poder prohibir las IP de ataque. Sería razonable hacerlo al instrumentar su código de cita de SQL (la parte que cita los datos entrantes para que sea seguro insertar en una consulta) para buscar listas de caracteres sospechosos. La mayoría de las cosas que espera insertar en las consultas serán simples textos o números, y encontrar caracteres de puntuación es muy sospechoso.

Tal vez le gustaría tener una vigilancia de retaguardia para los ataques que podrían haber tenido éxito, debido a errores en el procesamiento de su formulario. Debe tratar las consultas fallidas como extremadamente graves, registrarlas y enviar alertas. La mayoría de los intentos de inyección de SQL fallarán porque solo están adivinando cómo estructurar el SQL insertado.