Para entender esto partamos de la premisa de que las aplicaciones web toman sus datos de entrada de peticiones HTTP y en ciertas ocaciones de archivos para determinar cómo responder. Es decir, a veces los datos vienen por método POST, GET o PUSH.
La diferencia entre estos es básicamente la forma en la que se acomodan los datos. Hay una forma sencilla en la que nos podemos dar cuenta del método que utiliza el formulario para enviar los datos. Si el URL viene de la forma http://www.serv.org/form.php?var=valor&var2=valor2 significa que el archivo form.php recibe los datos por método GET, si no sería simplemente http://www.serv.org/form.php
Ahora, es posible puede modificar cualquier parte de la petición HTTP incluyendo la URL, la query string (cadena de petición), encabezados, cookies (galletas), campos de formas a fin de saltarse los mecanismos de seguridad del sitio. Aquellos que hallan trabajado con PHP y tuvieron que modificar el valor de los register globals entenderán a lo que me refiero.
Los nombres comunes de estos ataques son: navegación forzada (forced browsing), inserción de comandos (command insertion), scripting de sitio cruzado (cross side scripting), inundación de búfer (buffer overfloews) , ataques de formato de cadenas (format string attacks), inyección SQL (SQL injection), envenenamiento de cookies (cooki poisoning) y manipulación de campos escondidos (hidden field manipulation).
Dependiendo del conocimiento del equipo de desarrollo o de los administradores a veces encontramos algunos intentos de protección mediante el filtrado de los datos de entrada, lamentablemente hay muchísimas formas de codificar la información, sin necesidad de llegar a la encripción. De lo que se desprende por obvias razones que es necesario llevar todos los parámetros de entrada hasta su forma más simple, de otro modo, es posible que dichos datos traigan contenido malicioso.
El lado trágico del asunto es que por lo general las aplicaciones web usan solamente mecanismos del lado del cliente para hacer la validación de los datos de entrada, casi siempre mediante JavaScript o algo peor. Lo que se olvida o no se tiene muy en cuenta en estos casos es que dicho mecanismo de validación es fácilmente evitable. Basta con desactivar la ejecución de los lenguajes de scripting para que deje de funcionar nuestra preciosa validación. De modo similar, podríamos incluso usar algún otro programa como telnet (sí, algo tan vil como eso) para generar nuestras propias solicitudes HTTP.
Muchos ataques que se basan en la corrupción de los datos y parámetros de entrada se detendrían simplemente validando esta información.
No hay comentarios.:
Publicar un comentario