Los 10 riesgos más comunes de las aplicaciones web según OWASP - versión 2010

OWASP, Open Web Application Security Proyect, entre muchos otros proyectos enfocados a la educación de los desarrolladores en los métodos de defensa de las aplicaciones web, publica todos los años su lista de los 10 más peligrosos riesgos de seguridad para aplicaciones web (OWASP Top 10 Application 
Security Risks – 2010), la cual me he permitido traducir para ustedes a continuación:

Los riesgos expuestos por la OWASP para este año 2010 en orden de importancia son:

A1 - Inyección.
Fallas de inyección, tales como inyecciones SQL, de comandos de Sistema Operativo y de LDAP, ocurren cuando datos no verificados se insertan en comandos y consultas. El atacante puede utilizar el intérprete de estos para introducir comandos no permitidos o acceder datos no autorizados.

A2. - Cross Site Scripting, XSS.
Las fallas de XSS suceden cuando una aplicación toma datos no autorizados y los envía al navegador sin la propia validación o códigos de escape. El XSS permite a los atacantes ejecutar scripts en el navegador de la victima que pueden secuestrar su sesión, modificar sitios web o redirigir al usuario a sitios web dañinos.

A3. - Autentificación y Manejo de Sesión Rotos.
Las funciones relacionadas con la autentificación y el control de sesión muchas veces no son implementadas correctamente, permitiendo a los atacantes comprometer claves de acceso, llaves de control y tokens de sesión, permitiendo a los atacantes asumir las identidades de las victimas.

A4. - Referecias directas a objetos inseguras.
Una referencia directa insegura ocurre cuando el desarrollador expone una referencia a una implementación interna de un objeto, tal como un archivo, directorio o claves y campos de bases de datos. Sin control de acceso a los mismos u otra protección, un atacante puede manipular este tipo de referencia para tener acceso a datos de forma no autorizada.

A5. - Cross Site Request Forgery (CRSF).
Un Ataque de CRSF, fuerza al navegador "logueado" de la victima a mandar un "request HTTP", incluyendo el cookie de sesión de la victima y cualquier otra información de validación de la victima a una aplicación web vulnerable. Esto permite al atacante forzar al navegador de la victima para acometer daños o estafas que la aplicación piensa son iniciados por un usuario legítimo.

A6. - Fallas de Configuración de Seguridad.
Una buena seguridad requiere tener una configuración segura definida y entregada para la aplicación en si misma, entorno, servidor de aplicación, servidor web, servidor de base de datos y plataforma. Todos estos ajustes deben ser definidos, implementados y mantenidos, ya que no necesariamente las partes del sistema son entregadas con dichas configuraciones por defecto. Esto incluye mantener todo el software al día, incluyendo todas las librerías de código usadas por la aplicación.

A7. - Almacenamiento criptográfico inseguro.
Muchas aplicaciones no protegen los datos sensibles, como números de tarjetas de crédito, números de identificación del usuario y credenciales de autentificación con los tipos de cifrado y hashing apropiados. Los atacantes pueden robar o modificar estos datos pobremente protegidos para conducir ataques de robo de identidad, fraudes de tarjetas de crédito y otros crímenes.

A8. - Fallas en restricción de acceso a URLs.
Muchas aplicaciones verifican los derechos de acceso antes de que el usuario acceda a la aplicación por primera vez, sin embargo este tipo de verificaciones deben efectuarse cada vez que cualquiera de las páginas de la aplicación sea accedidas, o los atacantes podrán forjar direcciones URL que accedan a páginas o recursos prohibidos.

A9. - Insuficiente protección en la capa de transporte.
Las aplicaciones frecuentemente fallan en los procesos de autentificación, cifrado y garantia de confidencialidad e integridad del trafico de red sensible. Cuando no fallan, entonces puede suceder que usen algoritmos de cifrado débiles, certificados expirados o inválidos, o que no los usen correctamente.

A10. - Redirecciones y reenvíos sin debida validación.
Las aplicaciones web, generalmente redirigen o envían a los usuarios a otras páginas y sitios web usando datos no validados para hacerlo. Sin la apropiada validación, los atacantes pueden pueden redirigir a las victimas a sitios de phishing o malware, o usar los reenvíos para acceder a páginas no autorizadas.

Nuevamente coloco a disposición del lector el enlace de la OWASP como en otros artículos ya que es una de las fuentes más importantes de información acerca de la seguridad de aplicaciones web en la actualidad.

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.

Nueva forma de Phishing: Tab-nabbing

Extremadamente peligrosa por su novedosa forma de engañar al usuario el "Tab-nabbing" o captura de pestañas ha llegado al vecindario de los ataques de phishing, mostrándo a quienes creían que los filtros anti-phishing habían terminado con el problema del abuso de esta técnica de robo de credenciales que aún falta mucho por hacer.

Esta nueva modalidad, se basa como primer orden en la infección de sitios con vulnerabilidades de cualquier tipo que permitan insertar código javascript en sus páginas. Desde un simple abuso de FTP por fuerza bruta, hasta técnicas avanzadas de Cross Site Scripting (XSS) son algunas de las herramientas de siempre para infectar sitios que no tienen las medidas de seguridad necesarias o cuyos programadores han descuidado la desinfección de los datos que reciben en formularios y otro tipo de entradas de información.

Esto desde ya lo hace muy peligroso, ya que el problema principal es que ya no se usa el e-mail como vector de ingreso. El usuario en este caso simplemente visitará un sitio que conoce como legal, pero que se encuentra infectado.

La técnica a partir es muy creativa e innovadora y se apoya en el constante uso por todos nosotros de múltiples pestañas o "tabs" de navegación. Mientras cargamos una cosa esperamos por otra y así ya nos hemos acostumbrado a hacer de las pestañas una de las más usadas herramientas del navegador.

En pasos cortos y sencillos la estafa sucede de la siguiente manera:

1. El usuario navega en una pestaña el sitio infectado el cual se comporta normalmente como siempre sin levantar sospecha.
2. Una vez que decide dejarlo y abrir otra pestaña, el javascript que infesta el sitio infectado empieza a escanear el historial de navegación.
3. Cuando el javascript del sitio infectado identifica que ha sido navegada la página original que el atacante intenta simular, sin que el usuario se de cuenta cambia la página infectada que está en la pestaña que se ha dejado atrás por la página de phishing. 
4. Como si esto fuera poco, extrae el icono pequeño que el sitio original usa para identificar sus pestaña (favicon.gif) y lo coloca junto con el título nuevo en la pestaña que contiene la página fraudulenta. Todo esto mientras el usuario navega en otra pestaña.
5. El usuario en algún momento regresa a la pestaña en donde está la página fraudulenta pero como la ventana ya ha sido abierta y revisada con anterioridad rara vez se fija en la dirección de la misma o en el certificado y asume que ha navegado una pestaña de más o que su sesión con el sitio original ha caducado.
6.  El usuario inserta el código de acceso y su clave sin problemas. Como en muchos casos la sesión del sitio original no muere hasta cerrar el navegador, la página fraudulenta lo redirige hacia el sitio original sin que el suaurio se entere que le han robado los datos y sin que quede rastro visible en el navegador a menos que se vaya a ver directamente a verificar el historial de navegación.

¿Que les parece?

A continuación les coloco un enlace a un vídeo que aunque está en inglés muestra de forma sencilla el proceso. Fíjense bien como cambia el icono de la pestaña mientras el usuario navega otra.

Aunque creo que ya han entendido la técnica y la gravedad de la misma, voy a explicarles porqué es tan peligrosa:

• El sitio atacante solo aparece si el usuario navega en otra pestaña el sitio original. Esto hace que los ataques sean mucho más certeros.
• La página atacante por la misma razón será denunciada más tarde, es decir tendrá más tiempo de vida útil y por ende los filtros ant-phishing la indexarán más tarde.
• Es una técnica totalmente nueva, o que hace que exista una ventana de oportunidad para el ataque mayor.
• Las vulnerabilidades de los sitios comunes son muchas, por lo que conseguir sitios para sembrar el código en javascript que procesa el ataque es muy fácil. Como prueba hace unos meses unos hackers rusos infectaron una media de 2 millones de sitios para efectos de generar tráfico en sitios que pagaron sus servicios.

Hasta la próxima.

SQL Injection: El enemigo más peligroso.

Una de las técnicas de hacking más temidas por los administradores de bases de datos y los desarrolladores web es el “SQL injection”, la cual consiste en insertar o “inyectar” código malicioso en las sentencias SQL comúnmente utilizadas en gran cantidad de procesos en las aplicaciones actuales.


Hoy en día una aplicación web que no tenga acceso a una base de datos tiene muy poco que ofrecer competitivamente hablando, y quizás es por esta razón primordialmente que esta práctica es tan temida.

¿Cómo funciona? muy simple. Fijémonos en una sentencia SQL muy simple que toma un dato obtenido desde un formulario de búsqueda para obtener los datos coincidentes con dicha información creada en ASP y con una variable (userinput) que será cambiada en tiempo de ejecución por el contenido que inserte el usuario en dicho formulario:


"SELECT * FROM usuarios WHERE login = ' " & userinput & "'"


Al recibir el contenido que el usuario inserta en el campo del formulario como por ejemplo su login la sentencia queda como:

"SELECT * FROM usuarios WHERE login = 'admin'"


Pero que sucedería si el hacker en lugar de “admin” inserta un trozo de sentencia SQL como el siguiente:

'; DROP TABLE usuarios --


La respuesta es simple: La sentencia definitiva quedaría de la siguiente manera:


'SELECT * FROM usuarios WHERE login = '';DROP TABLE usuarios --"


Para quienes no tienen conocimientos básicos de SQL también es fácil entender que a partir de dicho momento habríamos perdido completamente el contenido de la tabla “usuarios” en nuestro sistema.

Este ejemplo anterior es solo uno de los muchos tipos diferentes de SQL injection que existen, sin embargo es uno de los más siniestros. La pregunta más importante es la que surge inmediatamente después de este ejemplo: ¿Cómo puedo saber si mi sitio web es vulnerable al SQL injection? Y si es así, ¿cómo puedo prevenir esta técnica de intrusión tan peligrosa?

Ambas preguntas van de la mano, sin embargo y aunque no es la única medida a ser tomada para evitar este tipo de práctica y es solo un remedio temporal, les tengo un buen dato:

Simplemente verifiquen del lado del servidor (recuerden que del lado cliente el “javascript “se puede deshabilitar) que el contenido que inserta el usuario no contenga comillas simples (las que normalmente se encuentran bajo el símbolo de interrogación en los teclados en español), y reemplácenlas por la entidad HTML de escape correspondiente (')

Existen muchos otros métodos de SQL injection que me comprometo a tratar en otros artículos, e indudablemente la solución que acabo de dar es solo una simple aspirina, pero como la aspirina misma es útil en el 50% de los casos.

Hasta la próxima…

Los servicios de recorte de URLs y el Cybercrimen

Este resumen no está disponible. Haz clic aquí para ver la publicación.