SQL Injection full analisys – Parte I

Si bien todo trabajo de “Ethical Hacking” o “Penetration Test” suele ser algo entretenido, cada nueva tarea representa un desafío plagado de responsabilidades. En este sentido, el sigilo es parte integral de nuestra labor: resulta indispensable realizar el máximo esfuerzo por pasar inadvertido frente al equipo de seguridad de la información del cliente. Sólo de ese modo estaremos desplegando nuestra mayor energía para simular un ataque lanzado por intrusos de nivel avanzado.

A menudo, el cliente focaliza gran parte de su estrategia de seguridad en el perímetro, y en menor medida en sus sistemas de detección de intrusos. No es mala idea, aunque por lo general puede no ser suficiente.

En los próximos párrafos nos centraremos en algunas de las prácticas más comunes de detección y evasión de SQL Injection, un ataque del tipo de validación de entrada, que ha tenido a maltraer a más de una Organización.

Como es sabido, los embates de SQL Injection suceden a nivel de Capa 7, la llamada “capa de aplicación”. Como en tantos otros ataques, el principal problema es de orden semántico, o sea, cómo son interpretados determinados caracteres de significado especial para aplicaciones y bases de datos. Otro aspecto interesante es que si el IDS/IPS no se halla específicamente configurado a tal efecto, los ataques pueden no ser detectados.

Más allá de su poder heurístico, con frecuencia los sistemas de detección de intrusos se basan en comportamientos o en firmas. De este modo, todo IDS/IPS posee su propio conjunto de reglas actualizables de detección específica. Si bien desde la teoría es factible identificar por medio de firmas las diferentes variantes de un ataque de SQL Injection, en la realidad suele ser casi imposible.

Usted se estará preguntando qué significa esto. Es simple: la protección contra ataques de SQL Injection por medio de sistemas basados en firmas no es “práctica”. Por más completa que resulte su base de datos de firmas, y suponiendo que está cubriendo todas y cada una de las variantes, el mantenimiento, las cuestiones de performance y los falsos positivos probablemente compliquen su operatividad y lo conviertan en una solución “impráctica”.

Firmas y más firmas

Veamos algunos ejemplos. La detección basada en firmas se encuentra ligada a la construcción de expresiones regulares especialmente dispuestas, a fin de que nos permitan advertir tantas variaciones de un ataque en particular como sea posible.

Un modelo típico que Usted seguramente ya ha visto alguna vez implementado como parte de una solución en SNORT, lucirá del siguiente modo:

SQL Injection full analisys – Parte II.

Alternativas de Evasión.
Una cuestión de espacios y comentarios.
Conclusión.