La importancia de la desinfección de parámetros para evitar ataques en la web

La razón más frecuente por la cual los sitios web sufren ataques de XSS (Cross Site Scripting), SQL inyection así como de otros tipos, se debe primordialmente a la falta de previsión por parte de los programadores a la hora de “Desinfectar los datos recibidos” desde la web o de terceros que pudieran sufrir del mismo problema.

La primordial razón para que un hacker pueda generar un ataque de este tipo a nuestra base de datos y a nuestros usuarios se debe primordialmente a lo anteriormente expuesto y la aceptación de parámetros infectados a su vez se debe a causas como:

Exceso de confianza: El programador no cree que su sitio por diversas razones amerite ser atacado por con alguno de estos métodos debido a que es un sitio común, no transaccional y que no mueve dinero. Lo anterior es falso, ningún sitio está a salvo actualmente debido a que si bien su sitio puede no ser blanco directo de una estafa, puede ser utilizado como redirección confiable de la misma o peor aún como distribuidor de la misma.

Inocencia a la hora de desinfectar los datos: Un desconocimiento de las técnicas básicas de XSS y “SQL Inyection” en la mayoría de los casos es el culpable de esta “inocencia” que genera sistemas de desinfección ineficientes.

Aumento de las rutinas de interacción con el usuario: Los programadores están acostumbrados a recibir datos por el URL o por un formulario. Si bien las técnicas AJAX y los componentes WEB 2.0 utilizan los mismos sistemas de paso de parámetros, como han sido creados por terceros se pudiera llegar a la falsa idea de que tratan el problema por defecto, lo cual en la gran mayoría de los casos es falso. Cualquier procedimiento que tome parámetros bien sea del usuario o de otras fuentes como bases de datos de terceros y servicios web, debe desinfectar dichos datos.

Grandes volúmenes de código y la carencia de rutinas centralizadas para el tratamiento de los datos: Cundo se generan cientos de páginas web, una gran mayoría de estas recibe parámetros. La falta de una rutina que centralice todas las solicitudes y redirija las mismas a las rutinas correspondientes, es la razón por la cual siempre escapa una rutina en la cual los datos no son validados correctamente. Bien sea por descuido o intervención de varios programadores en un mismo proyecto, a medida que una aplicación tiene más rutinas tiene más entradas de datos y por consiguiente más problemas de desinfección.

Creer que solo los campos de texto son vulnerables: En manos de personas expertas, todo parámetro o campo es vulnerable a infección. En un formulario forjado, lo que para nosotros es un “checkbox”, para un hacker es una entrada más de información en la que puede incluir código infectado. Lo mismo va para las listas y otros campos con entradas predefinidas.

Confiar en la validación del lado cliente en Javascript: Esto es un error muy común, basta solo desactivar el javascriopt para hacer que un formulario de datos se comporte de forma completamente impredescible para el sistema.

Para no entrar en detalle y aburrir, vamos a dejar las causas y entremos en las posibles soluciones:

• Estudio por parte del programador de las técnicas básicas de XSS y SQL Inyection (y otras): Una de las mejores fuentes de aprendizaje para un programador web es el OWASP (Open Web Application Security Proyect) http://www.owasp.org/index.php/Main_Page . Allí encontrará libros y artículos de seguridad web así como el proyecto WebGoat que consiste en una aplicación web auto instalable en su equipo, que deberá ser atacada por usted mediante técnicas que aprenderá paso a paso.

• Uso de APIs y librerías de desinfección de código:
  Para disminuir el esfuerzo requerido en grandes proyectos en referencia a la desinfección y control de parámetros, existen proyectos interesantes entre los cuales caben destacar los proyectos AntiSamy de OWASP para diferentes plataformas, que son simplemente APIS que permiten asegurar que los datos recibidos desde el cliente no contienen código maligno. Para aquellos que programen en ASP.NET , Microsoft pone gratis a disposición del programador la librería Microsoft Anti-Cross Site Scripting Library

• Centralización de las rutinas de recolección de desinfección de parámetros: Si su proyecto es razonablemente grande y debe evolucionar en manos de varios programadores, entonces debería empezar a pensar en generar una rutina única de recepción de parámetros. Esta rutina debe recoger los parámetros recibidos y enviarlos a las rutinas correspondientes ya depurados, así usted dejará de preocuparse por la desinfección de parámetros y otros asuntos de seguridad para los cuales tendrá que hacer revisiones en una sola rutina centralizada.

Espero que estos consejos les sean útiles para prevenir ataques de varios tipos de ahora en adelante, sin embargo recuerde un último consejo: No asuma absolutamente en cuanto a la desinfección de los datos, los atacantes se basan precisamente en vulnerar las posiciones comúnmente asumidas por los programadores.