Como se percibe en el ejemplo anterior, la inserción de un caracter adicional (N), le “dice” al SQL Server que el siguiente string debe ser tratado como nvarchar.

Este hecho no altera en nada la comparación desde el punto de vista de la lógica utilizada, pero sí podría afectar la identificación por firmas, pues el string resultante ya no es el mismo. Del mismo modo, los ejemplos dispuestos a continuación también podrían tener alguna posibilidad de no alterar su IDS:

Cada uno de los strings luce de forma diferente respecto de firmas estáticas: aunque algunos son muy distintos entre sí, todos comprenden un “string de condición verdadera” capaz de provocar situaciones indeseadas en aplicaciones vulnerables. En rigor de verdad, lo que se muestra en estos ejemplos es que por cada firma inventada, una nueva técnica de evasión puede ser diseñada.

Por otra parte, si bien una alternativa es construir firmas genéricas, esto conlleva el crecimiento exponencial de los falsos positivos, situación que en ciertas circunstancias puede ser aún peor que la enfermedad (a menudo el OR puede ser parte de código válido; en otras circunstancias, sencillamente podría reemplazarse por su valor encodeado).

Una cuestión de Espacios y Comentarios:

Honestamente, las posibilidades son muchas y dependen bastante de la inventiva del testeador o intruso. Una técnica de evasión muy habitual se basa en la interpretación de los espacios como parte de una sentencia SQL. Si bien la mayoría de las firmas considera las combinaciones con espacios (comúnmente utilizadas), aún sigue habiendo opciones no contempladas.

En este caso me refiero a la simbolización de comentarios “like C”, utilizada por Microsoft SQL, que si bien es desconocida por gran parte de los desarrolladores SQL, se halla implementada y disponible. Veamos el ejemplo:

En estos payloads hemos incluido varios caracteres que aunque no tienen injerencia desde el punto de vista de la lógica SQL (¡son válidos y las sentencias reales siguen siendo ejecutables!) podrían no coincidir con la firma tradicional que Usted suele incluir en la configuración de su IDS.

Conclusión

Variadas son las técnicas que pueden ser empleadas al momento de intentar la evasión de firmas, respecto de una especie de ataque en particular, como SQL Injection. Sin embargo, no todo es tan sencillo y muchos IDS/IPS seguramente ya habrán previsto las distintas alternativas, aunque si Usted ha prestado atención a estas líneas, tendrá la oportunidad de revisar la configuración de sus sistemas de detección de intrusos y verificar el modo en que este tipo de reglas se encuentran implementadas.

Por último, numerosos son los consejos que podrían brindarse a los efectos de mejorar su postura detectiva, aunque prefiero recordarle que cuando hablamos de SQL Injection, no existe mejor contramedida que las buenas prácticas de programación: nunca olvide que si una aplicación no es vulnerable, nunca deberá complicarse con cuestiones tales como detección y evasión.