1

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY

APROSEC: ASPECTO PARA LA PROGRAMACIÓN DE APLICACIONES

WEB SEGURAS

TESIS QUE PARA OPTAR EL GRADO DE MAESTRO EN CIENCIAS COMPUTACIONALES

PRESENTA

GABRIEL HERMOSILLO RODRÍGUEZ

Asesor: Asesor Externo:

Dr. Roberto Gómez Cárdenas PhD. Lionel Seinturier

Comité de tesis: Dr. Felipe Rolando Menchaca García Dr. Eduardo García García M.C. Adolfo Grego Kibrit M.C. Arturo García Hernández

Jurado: Presidente Secretario Vocal Vocal Vocal

Atizapán de Zaragoza, Edo. Méx., Abril de 2008.

2

3

DEDICATORIA

A mis padres quienes me brindaron siempre su apoyo incondicional y toda la motivación que me ayudaron a cumplir siempre con mis sueños.

4

AGRADECIMIENTOS

A mi asesor, el Dr. Roberto Gómez Cárdenas, por todo su apoyo y en especial por su amistad.

A mi futura esposa, Patricia Jaimes, por darme la oportunidad de lograr esta meta y por estar siempre a mi lado en todo momento.

A mis padres por darme ánimo en mis horas de desvelo.

A Laurence Duchien y Lionel Seinturier por su guía en este proyecto.

Al laboratorio Franco­Mexicano de Informática por financiar en parte la investigación de este proyecto.

5

6

RESUMEN

El uso de aplicaciones en Internet ha crecido de manera exponencial, siendo estas aplicaciones la principal base de negocio para muchas empresas. Los usuarios buscan nuevas y mejores experiencias en la red y tratan de realizar gran parte de sus actividades en línea. Las empresas tratan de cubrir estas necesidades ofreciendo cada vez más servicios, pero al hacer esto se exponen a que algunos usuarios malintencionados se aprovechen de las vulnerabilidades de sus aplicaciones y puedan penetrarlas, obteniendo acceso a información sensible, modificando o borrando datos importantes y haciendo que la imagen de la empresa se vea afectada ante sus usuarios.

Entre las más comunes y peligrosas vulnerabilidades que existen actualmente están el código cruzado entre sitios (XSS), la inyección de código SQL y la división de respuesta HTTP (HTTP Response Splitting). Entre las tres tienen cerca del 85% del total de las vulnerabilidades que se encuentran en las aplicaciones en línea. Todas ellas son causadas por errores y descuidos durante el desarrollo de las aplicaciones, lo que hace más complicado el solucionarlas, pues implica una buena cantidad de tiempo que se debe dedicar a pruebas, detección y corrección de estas aplicaciones, y eso multiplicado por el número de lugares en donde podrían estar las fallas.

La programación orientada a aspectos ofrece una solución viable para este tipo de situaciones, ya que permite crear una capa alrededor de la aplicación, sin necesidad de modificar el código ya existente. Entre sus mayores ventajas está el mantenimiento, pues solamente se debe mantener el aspecto involucrado y con eso se reflejan los cambios en toda la aplicación a la que fue aplicado. La facilidad con la que se pueden agregar, mantener y hasta quitar los aspectos de una aplicación es tal, que ni siquiera hace falta contar con el código fuente de la aplicación para hacerlo.

En este proyecto se desarrolló un aspecto de seguridad llamado AProSec, que al ser agregado, protege las aplicaciones de las tres vulnerabilidades ya mencionadas. El aspecto fue implementado tanto en AspectJ como en JBoss AOP para ver las ventajas y comportamientos de cada una de estas alternativas. Al final, sin necesidad de hacer modificaciones a la aplicación vulnerable de prueba, se logró protegerla solamente con agregar el aspecto en cuestión de segundos.

7

CONTENIDO

1 INTRODUCCIÓN......................................................................................................................................12

1.1 VULNERABILIDADES Y ATAQUES ..........................................................................................................13 1.2 SOLUCIONES EXISTENTES Y PROPUESTAS ..............................................................................................13 1.3 ESTRUCTURA DE LA TESIS ....................................................................................................................14

2 MOTIVACIÓN Y JUSTIFICACIÓN........................................................................................................16

2.1 ESTUDIO DE VULNERABILIDADES DEWASC .........................................................................................17 2.2 PORCENTAJE DE VULNERABILIDADES....................................................................................................18 2.3 PORCENTAJE DE SITIOS VULNERABLES ..................................................................................................19

3 CÓDIGO CRUZADO ENTRE SITIOS.....................................................................................................21

3.1 NO PERSISTENTES ................................................................................................................................22 3.2 BASADOS ENDOM ..............................................................................................................................24 3.3 PERSISTENTES......................................................................................................................................25 3.4 EJEMPLOS DE ATAQUES DE XSS............................................................................................................27

4 INYECCIÓN DE CÓDIGO SQL...............................................................................................................29

4.1 EJEMPLOS DE ATAQUES DE INYECCIÓN DE SQL .....................................................................................30

5 DIVISIÓN DE RESPUESTA DE HTTP....................................................................................................33

5.1 ATAQUES DERIVADOS DE LA DIVISIÓN DE RESPUESTA DE HTTP.............................................................34 5.2 EJEMPLO DE ATAQUE DE DIVISIÓN DE RESPUESTA DE HTTP...................................................................34

6 PROGRAMACIÓN ORIENTADA A ASPECTOS...................................................................................38

6.1 DISPERSIÓN DE CÓDIGO ........................................................................................................................40 6.2 INTEGRACIÓN DE ASPECTOS A LA APLICACIÓN.......................................................................................42

7 DESARROLLO Y ATAQUE DE UNA APLICACIÓN WEB VULNERABLE .......................................46

7.1 SECCIONES DE LA APLICACIÓNWEB ....................................................................................................47 7.2 BASE DE DATOS DE LA APLICACIÓN.......................................................................................................53 7.3 VULNERABILIDADES DE LA APLICACIÓN ...............................................................................................55

7.3.1. Vulnerabilidades de inyección de SQL............................................................................................56 7.3.2. Vulnerabilidades de XSS.................................................................................................................60 7.3.3. Vulnerabilidades de HTTP Response Splitting.................................................................................63

7.4 UNA ALTERNATIVA EFICIENTE PARA CORREGIR LAS VULNERABILIDADES ...............................................68

8 APROSEC ..................................................................................................................................................69

8.1 CONFIGURACIÓN DEL ASPECTO.............................................................................................................72 8.2 CONSEJO DEAPROSEC .........................................................................................................................74 8.3 INTEGRACIÓN DE APROSEC CONASPECTJ ............................................................................................77 8.4 INTEGRACIÓN DE APROSEC CON JBOSSAOP.........................................................................................78

8

8.5 RESULTADOS DE APLICARAPROSEC.....................................................................................................80

9 PROYECTOS RELACIONADOS.............................................................................................................84

9.1 TRABAJOS RELACIONADOS CON LOS ATAQUES DE INYECCIÓN DE SQL YXSS.........................................84 9.2 TRABAJOS SOBRE SEGURIDAD CON PROGRAMACIÓN ORIENTADA A ASPECTOS .........................................85

10 RESULTADOS Y CONCLUSIONES........................................................................................................87

REFERENCIAS ..................................................................................................................................................89

9

LISTA DE FIGURAS

Fig. 2.1 Porcentaje de vulnerabilidad del estudio de WASC ..................................................... 18 Fig. 2.2 Porcentaje de sitios vulnerables del estudio de WASC................................................. 19 Fig. 3.1 Posibilidad de ataques XSS no persistentes ................................................................. 23 Fig. 3.2 Ataque de XSS persistente .......................................................................................... 23 Fig. 3.3 Posibilidad de ataque XSS por DOM........................................................................... 24 Fig. 3.4 Ataque de XSS basado en DOM.................................................................................. 25 Fig. 3.5 Posibilidad de ataque de XSS persistente..................................................................... 26 Fig. 3.6 Ataque de XSS permanente......................................................................................... 26 Fig. 3.7 Resultados del ataque de XSS permanente................................................................... 26 Fig. 6.1 Ejemplo de buena modularidad en Tomcat .................................................................. 40 Fig. 6.2 Ejemplo de dispersión de código en Tomcat................................................................. 41 Fig. 6.3 Comparación entre programación tradicional y AOP................................................... 41 Fig. 6.4 Proceso de incorporación de aspectos a la aplicación................................................... 43 Fig. 6.5 Analogía del prisma para separar aspectos................................................................... 44 Fig. 7.1 Esquema de interacción de una aplicación WEB ......................................................... 47 Fig. 7.2 Pantalla principal de la aplicación ............................................................................... 48 Fig. 7.3 Pantalla de autenticación ............................................................................................. 48 Fig. 7.4 Pantalla de registro...................................................................................................... 49 Fig. 7.5 Pantalla de catálogo..................................................................................................... 50 Fig. 7.6 Resultados de la búsqueda........................................................................................... 50 Fig. 7.7 Pantalla para agregar comentarios ............................................................................... 51 Fig. 7.8 Pantalla de comentarios insertados por los usuarios..................................................... 51 Fig. 7.9 Pantalla del carrito de compras de un usuario .............................................................. 52 Fig. 7.10 Pantalla con las ligas a otras tiendas .......................................................................... 52 Fig. 7.11 Pantalla de error de la aplicación ............................................................................... 56 Fig. 7.12 Inyección de SQL en la autenticación........................................................................ 56 Fig. 7.13 Ingreso como administrador a la aplicación ............................................................... 56 Fig. 7.14 Inyección de SQL dirigida en la autenticación........................................................... 57 Fig. 7.14 Ingreso como usuario a la aplicación ......................................................................... 58 Fig. 7.15 Resultado de una búsqueda normal............................................................................ 58 Fig. 7.16 Inyección de SQL con UNION en las búsquedas ....................................................... 59 Fig. 7.17 Usuarios y contraseñas en el catálogo de libros de la aplicación ................................ 60 Fig. 7.18 Inyección de HTML en el campo de búsqueda .......................................................... 61 Fig. 7.19 Resultado de la inyección de HTML.......................................................................... 61 Fig. 7.20 Captura de un comentario para un ataque de XSS...................................................... 62 Fig. 7.21 Resultado de un ataque de XSS simple ...................................................................... 62

10

Fig. 7.22 Liga de la aplicación a un sitio real............................................................................ 63 Fig. 7.23 Resultado de consultar una liga normal ..................................................................... 64 Fig. 7.24 Mensaje en la aplicación ocasionado por un ataque de HTTP RS............................... 66 Fig. 7.25 Cambio del contenido con JS en un ataque de HTTP RS ........................................... 66 Fig. 8.1 Interacción de una aplicación Web normal .................................................................. 70 Fig. 8.2 Interacción de una aplicación protegida con AProSec.................................................. 71 Fig. 8.3 Prevención de ataque con comilla en la autenticación.................................................. 80 Fig. 8.4 Prevención de ataque con diagonal invertida en la autenticación.................................. 80 Fig. 8.5 Prevención de ataque con UNION en la búsqueda ....................................................... 81 Fig. 8.6 Ataque de XSS al agregar un comentario..................................................................... 82 Fig. 8.7 Resultado de la inserción con la validación de AProSec .............................................. 82 Fig. 8.8 Insertar un comentario con etiquetas válidas................................................................ 82 Fig. 8.9 Resultado de un comentario con etiquetas válidas con AProSec .................................. 83

11

LISTADE TABLAS

Tabla 2.1 Estadísticas de vulnerabilidades del estudio de WASC ............................................. 17 Tabla 4.1 Fases para un ataque de inyección de SQL................................................................ 30 Tabla 6.1 Trabajos sobre la separación de intereses .................................................................. 39 Tabla 7.1 Tabla de usuarios en la base de datos. ....................................................................... 53 Tabla 7.2 Tabla de productos en la base de datos...................................................................... 54 Tabla 7.3 Tabla de carrito de compras en la base de datos. ....................................................... 54 Tabla 7.4 Tabla de comentarios sobre los productos en la base de datos. .................................. 54 Tabla 7.5 Tabla de ligas a otros sitios en la base de datos. ........................................................ 55 Tabla 8.1 Ejemplos de validaciones utilizando AProSec........................................................... 76

12

1 INTRODUCCIÓN

En la actualidad, la seguridad en las aplicaciones Web es un concepto que comienza a ser de vital importancia. La actividad en Internet se ha incrementado de manera exponencial en los últimos años y muchas empresas han comenzado a ofrecer una gran variedad de servicios a través de aplicaciones Web. Los ataques a estas aplicaciones también se han incrementado de forma importante y de la misma forma lo han hecho las consecuencias negativas de los mismos.

Los desarrolladores de las aplicaciones ya no deben enfocarse solamente a los usuarios y los requerimientos funcionales, sino que también deben pensar en la seguridad de la aplicación, los posibles puntos débiles y los ataques que podría recibir. Sin embargo, a la seguridad no se le toma la importancia debida durante el diseño e implementación de las aplicaciones, esto debido principalmente a que por restricciones de tiempo y presupuesto, los esfuerzos de los desarrolladores se concentran en los requerimientos funcionales.

Esto nos lleva a una implementación pobre, ineficiente e inadecuada de la seguridad, en donde ésta se incorpora tardíamente a las aplicaciones y en ocasiones únicamente se incorpora la seguridad una vez que la aplicación ha sido vulnerada. Un gran porcentaje de las aplicaciones existentes tiene problemas de seguridad que persisten desde el diseño y hasta la implementación, por lo que, sin importar el lenguaje utilizado, salen a la luz [1].

Además de todo esto, se tiene el problema de que la seguridad es un tema complejo, que requiere de una gran cantidad de conocimientos sobre los posibles errores que puedan ocurrir y los ataques que se puedan sufrir por ello. La mayoría de las aplicaciones no son desarrolladas pensando en seguridad, y la mayoría de los desarrolladores no tienen los conocimientos necesarios sobre el tema, lo que resulta en aplicaciones inseguras [2].

13

1.1 VULNERABILIDADES Y ATAQUES

Dentro de la lista de los diez ataques más comunes, de acuerdo con el listado del proyecto abierto de seguridad de aplicaciones Web (OWASP 1 por sus siglas en inglés), existen dos principales ataques a las aplicaciones Web: Código cruzado entre sitios (XSS 2 ) e inyección de código SQL [3]. Ambos ataques son causados por la falta de validación en las entradas de información proporcionadas por el usuario. Otros análisis de seguridad muestran también a los ataques de división de respuesta de HTTP como una amenaza considerable.

El XSS es un ataque que explota una vulnerabilidad en un sitio Web que no valida los parámetros introducidos por un usuario. Utiliza varias técnicas para inyectar y ejecutar código escrito en lenguajes como JavaScript y VBScript. El objetivo de este ataque es interceptar las cookies que contienen información referente al usuario en el sitio, o engañar al usuario, proporcionándole formularios falsos, para que proporcione información personal o confidencial al atacante.

La inyección de código SQL es una técnica en donde un atacante modifica una petición de SQL válida para incluir en el resultado información confidencial, agregar o eliminar información de la base de datos o procesar comandos peligrosos en el servidor de base de datos. Esto sucede cuando la aplicación obtiene datos proporcionados por el usuario y sin validarlos los utiliza directamente para construir peticiones de SQL para la base de datos.

La división de respuesta de HTTP consiste en agregar encabezados a las peticiones de HTTP para alterar la respuesta del servidor o redirigir la petición a una nueva aplicación, sin que el usuario se de cuenta. El atacante aprovecha la falta de validación cuando una aplicación utiliza información proveída por el usuario para construir un encabezado de HTTP, comúnmente la dirección a la que lo va a mandar, e inyecta sus propios encabezados.

1.2 SOLUCIONES EXISTENTES Y PROPUESTAS

Para evitar este tipo de ataques se han propuesto varias soluciones, pero son muy complejas y poco eficientes. El principio de diseñar pensando en seguridad sugiere que la seguridad debe ser considerada en todas las etapas del ciclo de desarrollo y debe tener una gran influencia en el diseño de la aplicación. El problema es que la mayoría de los desarrolladores no contempla esta parte al realizar las aplicaciones y el corregir las aplicaciones ya existentes lleva mucho tiempo, sin tener la certeza de haber corregido todos los lugares en donde no se valida la información.

1 OWASP: The Open Web Application Security Project. 2 XSS: Cross Site Scripting.

14

En muchas ocasiones la empresa ya no cuenta con los desarrolladores originales ni la documentación adecuada de la aplicación, o en el peor de los casos ni siquiera tiene el código fuente para poder corregirla y optimizarla. Es por esto que el mayor problema en la seguridad computacional es precisamente el software, pues aunque contemos con una infraestructura muy bien protegida y vigilada, las aplicaciones siguen dando una puerta de acceso para los atacantes [4].

Una solución para este tipo de problemas es la programación orientada a aspectos (AOP 3 ), un paradigma de programación presentado en 1997 por Gregor Kiczales y su equipo de investigación de Palo Alto Research Center [5]. Consiste en separar la lógica de negocio de una aplicación de los conceptos que la complementan, como la seguridad, al concentrar cada uno de ellos en el mismo lugar, para evitar que estén dispersos en todas las clases y métodos del código fuente. Provee mecanismos, específicos para cada lenguaje de programación, que permiten integrar conceptos de manera modular, incorporándolos a la aplicación en tiempo de compilación o de ejecución.

El objetivo de este proyecto es diseñar e implementar un aspecto de seguridad llamado AProSec para combatir los ataques de inyección de código SQL, de código cruzado entre sitios y de división de respuesta de HTTP, utilizando la programación orientada a aspectos con dos implementaciones diferentes, una basada en el modelo que ofrece AspectJ y otra en el modelo de JBoss AOP [6][7]. En el la implementación para AspectJ, el aspecto se integra a la aplicación en tiempo de compilación, mientras que en la implementación para JBoss AOP se puede hacer tanto en tiempo de compilación como en tiempo de ejecución.

1.3 ESTRUCTURA DE LA TESIS

En el capítulo 1, Introducción, se muestra un panorama general de los problemas y la solución que se propone dentro de este proyecto.

En el capítulo 2, Motivación y justificación, se muestran las causas de dieron origen a este proyecto de tesis, así como los datos que sustentan su importancia.

En los capítulos 3, Código cruzado entre sitios, 4, Inyección de código SQL, y 5, División de respuesta de HTTP, se explican más a detalle las vulnerabilidades y la manera en que son explotados por los atacantes.

En el capítulo 6, Programación orientada a aspectos, se detalla el origen de este paradigma, la terminología que utiliza y los usos que se le puede dar.

3 AOP: Aspect Oriented Programming (Programación orientada a aspectos).

15

En el capítulo 7, Desarrollo y ataque de una aplicación Web vulnerable, se explica las partes que componen la aplicación, las secciones que son vulnerables y ejemplos de ataques a la aplicación.

En el capítulo 8, AProSec, se detalla el aspecto de seguridad de este proyecto y su implementación en dos plataformas distintas. Se muestran los ataques del capítulo 7 y la manera en que el aspecto protege a la aplicación.

En el capítulo 9, Proyectos relacionados, se hace una reseña de los proyectos que se han realizado para tratar de solucionar problemas similares a los que se presentan en este trabajo.

Finalmente en el capítulo 10, Resultados y conclusiones, se muestran los resultados obtenidos con la aplicación de AProSec, las publicaciones realizadas sobre el tema y las conclusiones del proyecto.

16

2 MOTIVACIÓN Y JUSTIFICACIÓN

La seguridad perimetral se ha robustecido en las empresas de manera importante, para evitar que los atacantes puedan tener acceso a sus servidores y con ello apoderarse de información confidencial o destruir archivos importantes. El uso de contrafuegos, detectores de intrusos, entre muchas otras herramientas, ha ayudado a evitar en gran medida estas intrusiones, sin embargo, la necesidad de ofrecer diversos servicios a los usuarios, como información en páginas Web, libros de visitas electrónicos, entre otros, genera una oportunidad para que los atacantes se aprovechen de los servicios vulnerables, ya que no pueden ser protegidas por ninguna las medidas anteriores.

Las vulnerabilidades se provocan porque los desarrolladores de estos servicios no le dan la importancia necesaria a los aspectos de seguridad al diseñar las aplicaciones, ya sea por ignorancia, por descuido o por imprudencia. Para apoyar a que los desarrolladores diseñen y generen aplicaciones más robustas, el OWASP creó una lista de las 10 vulnerabilidades más comunes en las aplicaciones [3]. Su principal objetivo es educar a los diseñadores, desarrolladores, arquitectos de software y a las organizaciones en general acerca de las consecuencias de estas vulnerabilidades, así como de la manera en que se pueden prevenir al desarrollar las aplicaciones.

Entre las vulnerabilidades contempladas en el listado del OWASP, en las primeras dos posiciones están el código cruzado entre sitios (XSS) y la inyección de código SQL. Ambas vulnerabilidades son provocadas por la falta de validación de la información proporcionada por el usuario al sistema. Al ser un error humano en el diseño de la aplicación y la manera en que está desarrollada, y no un problema con en el lenguaje de programación, el sistema operativo o el servidor de aplicaciones, no existe un parche que permita solucionar este problema de manera automática.

OWASP no es la única organización que hace referencia a estos ataques y los clasifica como peligrosos. Tanto en el WASC 4 como en el CVE International 5 , se hace mención sobre estos ataques y se les clasifica dentro de los primeros lugares [8][9]. En la tabla 2.1 se pueden observar

4 WASC: Web Application Security Consortium (Consorcio de seguridad en aplicaciones Web). 5 CVE: Common Vulnerabilities and Exposures (Vulnerabilidades y exposiciones comunes).

17

las estadísticas que ofrece WASC sobre un análisis realizado a varias aplicaciones Web, utilizando técnicas de escaneo automatizadas. Para obtener los resultados se utilizaron herramientas como WhiteHat Sentinel, SPI Dynamics WebInspect, Positive Technologies MaxPatrol y Cenzic Hailstorm.

2.1 ESTUDIO DE VULNERABILIDADES DE WASC

El estudio se realizó de enero a diciembre de 2006, probando un total de 31,373 sitios. El resultado se obtuvo con la combinación de la información en crudo de los escaneos automatizados y de información validada de manera manual para eliminar los falsos positivos. Se presentan dos tipos de resultados, uno por vulnerabilidades y otro por sitios vulnerables, ambos presentados en número y porcentaje del total para facilitar su entendimiento. En la tabla resalta principalmente el gran número de vulnerabilidades de XSS y el gran número de sitios en el que se encontraron.

Tabla 2.1 Estadísticas de vulnerabilidades del estudio de WASC

# % # % Brute Force 66 0.04% 66 0.21% Content Spoofing 663 0.45% 218 0.69% Cross Site Scripting 100,059 67.59% 26,531 84.57% Directory Indexing 292 0.20% 168 0.54% HTTP Response Splitting 4,487 3.03% 3,062 9.76% Information Leakage 20,518 13.86% 4,924 15.70% Insufficient Authentication 84 0.06% 1 0.00% Insufficient Authorization 23 0.02% 4 0.01% Insufficient Session Expiration 46 0.03% 1 0.00% OS Commanding 143 0.10% 44 0.14% Path Traversal 426 0.29% 374 1.19% Predictable Resource Location 651 0.44% 173 0.55% SQL Injection 19,607 13.25% 8,277 26.38% SSI Injection 950 0.64% 298 0.95% XPath Injection 14 0.01% 6 0.02%

Amenaza Vulnerabilidades Sitios vulnerables

Hay cuatro vulnerabilidades que encabezan la lista en ambos rubros: Cross Site Scripting (XSS), SQL Injection, fuga de información y HTTP Response Splitting. De estos cuatro, hay solamente tres que involucran problemas relacionados directamente con las aplicaciones. La fuga de información se puede dar por varias razones, sin que estas involucren el funcionamiento de la aplicación, como pueden ser los comentarios que dejan los desarrolladores en las páginas visibles

18

para los usuarios, mensajes de error con información técnica o simplemente información sensible presentada al usuario sin solicitarlo.

A pesar de que la fuga de información por sí sola no representa una violación de seguridad, sí les da a los atacantes datos valiosos para poder realizar otros ataques y penetrar más fácilmente el sistema. Estos datos pueden ser nombres de computadoras, usuarios y contraseñas de sistema, bases de datos, tablas y campos, sistema operativo, etc. Haciendo uso de toda esta información los atacantes pueden enfocarse completamente al ambiente al que están trabajando, facilitándoles mucho la tarea de penetración.

2.2 PORCENTAJE DE VULNERABILIDADES

En la figura 2.1 se muestra la gráfica de los porcentajes de vulnerabilidades de los datos obtenidos en el estudio de WASC, donde se pueden observar con facilidad los ataques dominantes. Se ponen únicamente los primeros cuatro lugares y se agrupan todas las demás vulnerabilidades en una sola categoría para facilitar la lectura de la gráfica.

% Vulnerabilidades

13%

68%

3% 14% 2%

Cross Site Scripting Fuga de información

SQL Injection HTTP Response Splitting Los demás

Fig. 2.1 Porcentaje de vulnerabilidad del estudio de WASC

Como se puede ver en la figura 2.1, el conjunto de las cuatro principales vulnerabilidades suman el 98%. Este es un porcentaje alarmante, pues casi el total de las vulnerabilidades están concentradas en esos cuatro grupos. Es importante mencionar que todas ellas son ocasionadas por

19

descuidos de los desarrolladores, falta de validación en la entrada de información, malas prácticas de programación o simplemente por desconocimiento. Es por esto que las aplicaciones no pueden ser fácilmente arregladas con algún parche a los sistemas operativos, las bases de datos o los servidores de aplicaciones.

2.3 PORCENTAJE DE SITIOS VULNERABLES

En la figura 2.2 se muestra ahora el porcentaje de los sitios que son vulnerables a los grupos mencionados en la gráfica anterior. De nuevo se muestran solamente las cuatro categorías más altas y las demás agrupadas en una misma categoría para facilitar la lectura de la gráfica. Es importante notar que las vulnerabilidades que resaltan en ambas clasificaciones son las mismas, por lo que se acentúa aún más su peligrosidad, pues son las que más se pudieron explotar y se encuentran en más sitios.

El XSS nuevamente encabeza la lista, mostrando que casi el 85% de los sitios que fueron probados son vulnerables a este tipo de ataques. En segundo lugar se muestran los ataques de inyección de SQL, seguido de la fuga de información y al final de los cuatro se encuentra el HTTP Response Splitting. La suma de todos los demás es de menos del 5%, aunque no por ello dejan de ser peligrosos y deben ser tomados en cuenta por los administradores de los sitios.

84.57%

26.38% 15.70%

9.76% 4.30%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Cross Site Scr ipting

SQL Injection Fuga de información

HTTP Response Splitt ing

Los dem ás

% Sitios vulnerables

Fig. 2.2 Porcentaje de sitios vulnerables del estudio de WASC

20

Con excepción de la fuga de información, las principales vulnerabilidades se deben a que los desarrolladores de las aplicaciones no cuidan, revisan y filtran las entradas que reciben por medio de parámetros, ya sea por medio de los formularios o por entradas directas en la dirección URL 6

de la aplicación. Esto permite que los atacantes hagan uso los parámetros de la aplicación para poder explotar estar vulnerabilidades, aparentando hacer un uso normal de la aplicación. Es por esta razón que los detectores de intrusos, los contrafuegos y todas las demás medidas de protección que se utilizan, no pueden detectar y detener estos ataques.

6 URL: Uniform Resource Locator (Localizador uniforme de recursos).

21

3 CÓDIGO CRUZADO ENTRE SITIOS

El código cruzado entre sitios (XSS) tiene sus inicios en 1996, cuando se iniciaba el comercio electrónico y las páginas en Internet comenzaban a volverse más dinámicas. Con el nacimiento de JavaScript, la interacción con las páginas las hacía más atractivas y permitía a los desarrolladores agregar efectos como imágenes que cambiaban al pasar el puntero sobre ellas, menús flotantes y las desquiciantes ventanas emergentes. Este nuevo mundo lleno de posibilidades para atraer nuevos visitantes a las mejores y más atractivas páginas, atrajo también la atención de los atacantes, quienes vieron en el JavaScript una potencial y muy poderosa arma que podrían utilizar a su favor.

Algunos desarrolladores crearon páginas en las que podían leer información de cualquier otro sitio, simplemente con incluir frames con la dirección del sitio a atacar y utilizar JavaScript en su página que obtuviera los datos que se ingresaban ahí. De esta manera, los atacantes podían evitar la barrera que existía entre los sitios y obtener datos confidenciales, usuarios, contraseñas, etc. Este problema fue atribuido a los navegadores y Netscape, quien dominaba ese mercado, se dio a la tarea de solucionarlo, por lo que propuso su “política de mismo origen”, en la que restringía que el código de un sitio pudiera acceder a la información de otro.

En diciembre de 1999, David Ross describió cómo el contenido en la Web podía saltarse las garantías de seguridad existentes y realizar inyección de código, pero en donde el problema provenía del servidor y no del cliente. Esto se expuso en un artículo interno de Microsoft en donde se describía el concepto, la manera de explotarlo, cómo hacer que el ataque persistiera por medio de las cookies, como podía ser utilizado por un virus y posibles soluciones. Eventualmente se compartió con el CERT 7 para informar al público y corregir los sitios vulnerables y fue revisado y publicado en febrero del 2000 [10].

El término Cross Site Scripting surgió de una lista de propuestas entre las que estaban: Unauthorized Site Scripting, Unofficial Site Scripting, Uniform Resource Locator (URL) Parameter Script Insertion, Synthesized Scripting y Fraudulent Scripting [11]. A principios de la

7 CERT: Computer Emergency Response Team (Equipo de respuesta a emergencias computacionales).

22

década del 2000, se sugirió utilizar el acrónimo XSS para evitar la confusión con el término Cascading Style Sheets (Hojas de estilo en cascada), que utilizaba el acrónimo CSS.

Hace algunos años, mucha gente pasaba por alto los ataques de XSS y no se le veía gran peligro, hasta que en octubre de 2005 surgió el gusano Samy Worm, el cual se propagó a más en un millón de usuarios en menos de 24 horas, utilizando el concurrido sitio de MySpace. El gusano utilizaba vulnerabilidades de XSS que tenía el sitio y se propagaba cada vez que algún usuario accedía a la página de un usuario contaminado [12]. Este incidente ocasionó que muchas miradas se desviaran hacia los ataques de XSS y en la actualidad se están realizando muchos trabajos para evitarlos y explotarlos.

Para que este tipo de ataques funcionen, la aplicación debe mandar al usuario código malintencionado, generalmente en JavaScript o VBScritp, y con esto ocasionar que al visitar la página, el navegador del usuario lo interprete. Existen varios escenarios en los que esto puede suceder:

1) El dueño del sitio puso el código intencionalmente. 2) El sitio fue cambiado por algún atacante y subió el código malicioso. 3) Una vulnerabilidad de XSS permanente podría ser explotada en un área pública de un

sitio Web vulnerable. 4) Una víctima podría haber dado clic sobre una liga maliciosa con un ataque no persistente

o basado en DOM de XSS.

Para entender un poco mejor los escenarios planteados, es importante explicar los diferentes tipos de ataques de XSS que existen: basados en DOM, persistentes y no persistentes [11].

3.1 NO PERSISTENTES

Los ataques de XSS no persistentes son los más comunes de los tres tipos y consisten en utilizar información que la aplicación muestra inmediatamente después de haber sido ingresada por el usuario. Un lugar común para encontrar este tipo de vulnerabilidades es en las búsquedas. Por ejemplo, en la figura 3.1 tenemos una aplicación realiza búsquedas y luego le muestra al usuario el texto que utilizó, lo cual funciona bien para búsquedas normales.

23

Fig. 3.1 Posibilidad de ataques XSS no persistentes

Como se muestra en la figura 3.1, la aplicación despliega en dos lugares el texto que se utilizó para la búsqueda. Esto puede ser utilizado por un atacante, como se muestra en la figura 3.2, inyectando código de JavaScript en la búsqueda que será mostrada de regreso al usuario.

Fig. 3.2 Ataque de XSS persistente

Una vez que el atacante ha terminado su código para explotar la vulnerabilidad, comenzará a publicar la liga por todos los medios que le sea posible, como correo electrónico, mensajería instantánea, blogs, etc. La finalidad es atraer a la mayor cantidad posible de usuarios incautos, para que den clic en la liga y sean víctimas del código malicioso. Lo que hace que este tipo de ataques sean tan peligrosos y efectivos es que los usuarios son más propensos a acceder a la liga, pues la dirección es la de un sitio real, no un nombre parecido o una dirección de IP que pueden generar desconfianza.

24

3.2 BASADOS EN DOM

El DOM 8 es una forma de representar los elementos de un documento estructurado, por ejemplo una página Web HTML o un documento XML, como objetos que tienen sus propios métodos y propiedades. Los ataques de XSS basados en DOM se realizan de una manera muy similar a los ataques no persistentes. Se pueden realizar cuando la aplicación tiene código del lado del cliente, como JavaScript, que utiliza los parámetros de la dirección URL para escribir código HTML en su misma página, sin utilizar algún tipo de validación. Por ejemplo, una aplicación que manda un mensaje el mensaje “Oferta de último minuto” al usuario, se puede llamar por medio de la siguiente dirección URL:

http://www.servidor.com/aplicacion?title=Oferta%20de%20%FAltimo%20minuto!

Esta dirección daría como resultado una pantalla como la que se muestra en la figura 3.3. Cualquier texto que se agregue a la dirección como valor del parámetro “ title” será desplegada en la aplicación.

Fig. 3.3 Posibilidad de ataque XSS por DOM

Este tipo de funcionalidad puede ser aprovechado por un atacante que fabrique una dirección URL que contenga algún código que sea ejecutado del lado del cliente, sin que exista interacción con el servidor de aplicaciones. En la figura 3.4 se muestra el resultado de utilizar la siguiente dirección URL:

http://www.servidor.com/aplicacion?title=<script>alert('Vulerable por

DOM!');</script>

8 DOM: Document Object Model (Modelo de objetos de documento).

25

El código que genera el título dinámico en la página no sospecha de la información que viene en la dirección y agrega tal como está el contenido del parámetro en la página, dando como resultado una vulnerabilidad.

Fig. 3.4 Ataque de XSS basado en DOM

3.3 PERSISTENTES

Los ataques persistentes son los más peligrosos de los tres. A este tipo de ataques se les conoce también como ataques de inyección de HTML. Para explotar este tipo de ataques es necesario que la información que provea un usuario sea almacenada por la aplicación y luego presentada a otros usuarios, sin ser validada antes. El término de ataques persistentes viene de que la información proveída por el usuario es almacenada y se presenta cada vez que se visita la página, sin necesidad de volver a atacar la aplicación.

Este tipo de ataques se realizan generalmente en blogs, foros de interés, retroalimentaciones o comentarios de usuarios sobre algún producto, correo HTML, wikis, entre muchos otros. Una vez que el usuario visita la página infectada, la ejecución del código es automática, lo cual hace que este ataque sea tan peligroso, pues deja al usuario con muy pocas posibilidades de defenderse, solamente deshabilitando el JavaScript en su navegador antes de visitar el sitio. Un ejemplo típico es el que se muestra en la figura 3.5, donde los comentarios ingresados por un usuario se muestran a todos los demás.

26

Fig. 3.5 Posibilidad de ataque de XSS persistente

Este tipo de sitios pueden ser vulnerables a ataques de XSS persistentes, pues almacenan la información que el usuario provee y la muestran a todos los usuarios cada vez que visitan el sitio. En la figura 3.6 se puede ver como se puede agregar un comentario malintencionado y en la figura 3.7 se muestra el resultado de que un usuario visite el sitio infectado.

Fig. 3.6 Ataque de XSS permanente

Fig. 3.7 Resultados del ataque de XSS permanente

27

Al igual que en los casos anteriores, los atacantes promoverán la liga hacia la página infectada, pero a diferencia de los otros, el ataque no está en la liga, sino en la página en sí. Como el ataque se encuentra dentro del contenido de la página y no en la dirección de la aplicación, es imposible saber si una liga a una aplicación nos mandará a una página normal o a un sitio comprometido. Es por esto que incluso los usuarios más astutos y precavidos pueden ser contaminados con estos ataques.

3.4 EJEMPLOS DE ATAQUES DE XSS

El alcance de los ataques de XSS está limitado solamente por el lenguaje que utilice, la capacidad del navegador para interpretarlo y la imaginación del atacante. El ataque puede ser tan sencillo como introducir un comentario en HTML (<!‐‐) que oculte el resto de la página. Si un atacante introduce en un formulario lo siguiente:

Esta sección está clausurada. Disculpe los inconvenientes. <!‐‐

Con esta entrada todo el contenido de la página, después del comentario, será ignorado por el navegador y el usuario no podrá ver el resto del contenido. Otro caso sería que el atacante terminara la sesión del usuario, enviándolo al logout del mismo sitio, introduciendo algo como esto:

<script>

window.location.href = "http://www.elsitio.com/Logout"; </script>

De esta forma, cada vez que un usuario tenga acceso a la información que puso el atacante, lo estarían reenviando a terminar su sesión. Si la información aparece en la primera página al iniciar la sesión, el usuario nunca podría pasar de ahí. Este tipo de técnicas se pueden usar también para bombardear o inundar a un usuario con popups con un código tan sencillo como este:

<script> for (q=0; q < 1000; q++) window.open(“http://www.publicidad.com”);

</script>

Y de la misma manera se puede hacer uso de la información que el sitio haya almacenado sobre el usuario en la cookie, pudiendo con esto secuestrar su sesión y obtener o modificar los datos que el usuario haya proveído al sitio. EL código puede incluso estar dentro de una etiqueta de HTML inocente, como una imagen, y además ser tan peligroso como el robo de la cookie del usuario:

28

<img src="javascript:document.location='http://www.malicioso.com/RobarCookie?'

+ document.cookie;">

Un ataque aún más peligroso que se puede realizar con las técnicas de XSS es el Phishing, y esto se puede realizar pues al tener la facilidad de ejecutar código de JavaScript del lado del cliente, también podemos alterar la página que está viendo. Para hacer esto, el atacante solamente necesitaría reemplazar el contenido de “document.body.innerHTML” con cualquier contenido que quiera que el usuario vea, manteniendo la misma dirección, encabezados y título de la página original, lo cual podría contener una forma similar a la que está familiarizada el usuario, pero donde el atacante estará guardando la información.

El utilizar protocolos criptográficos como SSL en el sitio, no protege al usuario contra ataques de XSS, pues a pesar de que dificultan otros tipos de ataques, estos se siguen llevando a cabo en el ambiente cifrado y la información sigue llegando en claro al atacante.

Este tipo de ataques están dirigidos completamente a los clientes del sitio, no al sitio en si. Además del robo de información, el ataque puede aprovechar alguna vulnerabilidad del navegador del usuario y afectar su computadora, utilizando su navegador como puente para atacar al sistema operativo. El XSS puede ser apoyado también por ingeniería social, ya que se puede enviar un correo con una dirección hacia un sitio confiable, que incluya algún código malicioso dentro de la misma dirección del sitio.

http://www.servidor.com/mensajes.jsp?buscar=<script>alert("Cookie:" +

document.cookie)</script>

A pesar de que el XSS está dirigido a los usuarios, el tener un sitio vulnerable afecta directamente a la empresa, pues al ser un ataque que se ejecuta en el navegador del usuario, se puede tener acceso a la Intranet de la empresa, evitando toda la seguridad perimetral con la que se contaba. Y aun cuando no alterara directamente la información del sitio, sí afecta la imagen y reputación del mismo, pues si se conoce que la información de sus usuarios está siendo expuesta, se verá con desconfianza y la empresa puede perder muchos usuarios y negocios importantes.

29

4 INYECCIÓN DE CÓDIGO SQL

Los atacantes no ven a la base de datos de la misma forma en que la ve un DBA 9 . Para un DBA la seguridad en la base de datos involucra un detallado control de acceso junto con algunas limitantes en los tamaños o cuotas de las bases de datos. Para un atacante, una base de datos es solamente el medio para alcanzar un fin, ya sea el obtener información a la que no debería tener acceso, o peor aun, tratar de conseguir privilegios de administrador en el servidor que está corriendo la base de datos.

La inyección de SQL es un ataque enfocado a atacar el servidor de la base de datos y no a los usuarios de la aplicación, aunque estos no quedan exentos si un atacante introduce código peligroso en la base de datos. Se aprovecha de las entradas no validadas para tratar de alterar los comandos de la aplicación a las bases de datos, con el fin de obtener información a la que no debería tener acceso, para alterar o borrar el contenido de las tablas o para utilizar la base de datos como puente para ejecutar comandos en el sistema operativo donde corre.

Las aplicaciones Web están construidas en varias capas, en un extremo está el navegador del usuario y en el otro la base de datos que contiene la información que el usuario quiere acceder. En medio se encuentran las capas de presentación y lógica de negocio, las cuales deciden cómo y qué información mostrar al usuario en cierto momento. Para esto, las aplicaciones utilizan información proporcionada por el usuario para construir peticiones de bases de datos, lo que da pie a que un atacante proporcione información intencionalmente formateada para alterar las peticiones y así eliminar ciertas validaciones o cambiar el resultado esperado.

En la tabla 4.1 se muestran las fases para realizar un ataque de inyección de SQL y su descripción. Cuando un atacante ha logrado alcanzar o superar la etapa 3, tenemos un escenario en el que nuestra empresa tiene graves problemas. Hasta el año 2001, era relativamente fácil encontrar aplicaciones Web que fueran vulnerables a ataques de inyección de SQL, pero a partir del 2002 comenzó a ser cada vez más difícil encontrarlas, sin embargo siguen existiendo [13].

9 DBA: Data Base Administrator (Administrador de bases de datos).

30

Muchas veces los desarrolladores confían demasiado en el usuario y se olvidan de validar las entradas que el usuario manda a la aplicación por medio de alguna forma. También es común encontrar aplicaciones que validan muy bien los formularios utilizando JavaScript y limitando ciertos campos con un tamaño máximo, pero no hacen las validaciones pertinentes en el código que corre en el servidor, lo cual permite al usuario realizar ataques simplemente con deshabilitar el JavaScript o guardar la página y alterar el código fuente para quitar las restricciones que necesite.

Tabla 4.1 Fases para un ataque de inyección de SQL

Etapa Descr ipción

1. Localizar vulnerabilidades de inyección de SQL

Consiste en encontrar los lugares de la aplicación en donde se puede introducir información que será utilizada para generar peticiones a la base de datos, ya sea analizando las respuestas de la aplicación o los mensajes de error, en caso de que los muestre.

2. Ingeniería en reversa a la petición de SQL vulnerable

En esta etapa, el atacante intenta producir mensajes de error al inyectar diferentes peticiones de base de datos, para poder descifrar las peticiones originales que está realizando la aplicación.

3. Obtener los resultados de peticiones arbitrarias de SQL

Aquí el atacante busca la manera de obtener la información resultante de las peticiones inyectadas por varios métodos, desde mostrar los resultados en una página de la aplicación, hasta enviar las respuestas vía Internet a un servidor externo.

4. Enumeración de privilegios

Durante esta etapa, se intentará obtener la mayor cantidad de información que sea posible encontrar, con la finalidad de poder explotarla después dentro de la misma aplicación o en otros servidores.

5. Penetración de la infraestructura

Finalmente, el atacante intentará apoderarse del servidor, obteniendo los privilegios de administrador o insertará algún troyano que le permita conservar el control.

4.1 EJEMPLOS DE ATAQUES DE INYECCIÓN DE SQL

La falta de validación en el código que corre en el servidor también hace que la aplicación sea vulnerable si le mandan parámetros desde la dirección de la aplicación (URL), por lo que un

31

atacante podría evitarse cualquier validación simplemente con ver el nombre de los parámetros que mandaría una forma y agregarlos a la dirección de la aplicación, antecedidos por el símbolo “?” y separando cada pareja de “parámetro=valor” por un símbolo “&”.

Por ejemplo, una forma que valide los campos de “usuario” y “nip”, poniendo como límite de caracteres 8 para usuario y 6 para nip y con la condición de que el campo de nip sea únicamente numérico, no permitiría los valores:

Usuario: miUsuario

Nip: miNuevoNip

Pero, si le pasamos directamente los parámetros en la dirección:

http://www.misitio.com/ValidaUsuario?usuario=miUsuario&nip=miNuevoNip

Entonces la aplicación recibirá parámetros fuera del tamaño y tipo esperado, lo que podría ocasionar un error en la misma aplicación o en la base de datos, en caso de ser almacenados. Estos errores en ocasiones son aprovechados por los usuarios maliciosos para ir conociendo el sistema al que están atacando.

Un ejemplo para demostrar un ataque básico de inyección de SQL, es una validación donde la aplicación le pide al usuario su nombre y contraseña para poder acceder. Al momento de que un usuario normal llega a la aplicación, introduce sus datos en el formulario:

Usuario: nombre

Contraseña: mipwd

La aplicación toma estos datos para construir un comando de SQL para la base de datos de la siguiente forma:

SELECT *

FROM usuarios WHERE login = 'nombre'

AND pwd = 'mipwd'

Este comando regresaría todos los datos contenidos en la tabla “usuarios” si existiera un usuario “nombre” con contraseña “mipwd”. En caso de que el usuario o la contraseña estén incorrectos, la consulta no regresa nada y la autenticación se rechaza. En este escenario todo parece funcionar correctamente y para muchos desarrolladores, esta rutina de autenticación es lo suficientemente robusta. Sin embargo, el exceso de confianza, el desconocimiento y la desidia son los principales enemigos de los desarrolladores para la creación de aplicaciones seguras.

32

Si un atacante decide salirse del estándar e introduce en el formulario caracteres especiales como comillas y guiones o signos de número, la aplicación sigue pasando esta información directamente a la base de datos, sin considerar que al interpretarlos, la base de datos puede funcionar de una manera inesperada. Si por ejemplo, el atacante decide mandar las entradas:

Usuario: admin Contraseña: x' or 1=1‐‐

La aplicación seguiría tomando estos datos y usándolos para construir los comandos de la base de datos, que quedarían como sigue:

SELECT * FROM usuarios

WHERE login = 'admin' AND pwd = 'x' or 1=1‐‐'

Como se puede apreciar, ahora la consulta busca al usuario “admin” con una contraseña “x”, pero con la diferencia de que la condición ahora incluye una nueva cláusula: “or 1=1”, la cual siempre será verdadera. El sistema buscará a un usuario “admin” y en caso de existir, sin importar si la contraseña corresponde o no (por la cláusula nueva), se dará la autenticación exitosa como el usuario “admin”.

Si no se tiene un nombre de usuario conocido, también se puede agregar la tautología en el campo del usuario, quedando de la siguiente manera:

Usuario: loQueSea' or 1=1‐‐ Contraseña: noImporta

Lo que generaría, al construir la petición a la base de datos, un comando como el este:

SELECT *

FROM usuarios WHERE login = 'loQueSea' or 1=1‐‐'

AND pwd = 'noImporta'

Al utilizar la tautología en el campo del nombre de usuario, seguida del comentario, la base de datos va a buscar a los usuarios con nombre “loQueSea” o donde “1=1” y con el comentario se ignora la condición de la contraseña. Esto regresaría a todos los usuarios de la tabla y la aplicación generalmente tomaría al primero que le de la base de datos y al no estar vacía la consulta, le daría al atacante la autenticación con el usuario que tomó.

33

5 DIVISIÓN DE RESPUESTA DE HTTP

Los ataques de división de respuesta de HTTP (HTTP Response Splitting) se basan en que el atacante pueda inyectar una nueva línea y retorno de carro (CRLF 10 ) dentro de los encabezados de respuesta. De acuerdo con el estándar RFC 2616, la secuencia CRLF separa a un encabezado de otro, por lo que si un atacante logra inyectar esa secuencia, podrá poner tantos encabezados desee [14].

Para poder llevar a cabo un ataque de división de respuesta de HTTP, se requiere por lo menos de tres partes involucradas:

1) Servidor Web: Contiene una aplicación vulnerable a ataques de respuesta dividida de HTTP.

2) Víctima: Una entidad que interactúa con el servidor Web, generalmente el navegador del usuario o un servidor de caché.

3) Atacante: Quien intentará explotar la vulnerabilidad y ejecutar el ataque.

Un ataque de división de respuesta de HTTP consiste en que un atacante envíe una petición de HTTP que fuerce al servidor Web a generar una salida que sería interpretada por la víctima como dos respuestas de HTTP, en lugar de una. La primera respuesta puede ser controlada parcialmente por el atacante, pero la segunda la controla por completo, lo que le permite generar una gran variedad de ataques, entre los que destacan el envenenamiento de caché (del navegador o incluso de un servidor de caché), ataques de XSS y secuestro de páginas [15].

10 CRLF: Carriage Return Line Feed.

34

5.1 ATAQUES DERIVADOS DE LA DIVISIÓN DE RESPUESTA DE HTTP

• Ataques de XSS: Antes, para realizar un ataque de XSS por medio de una redirección, el atacante necesitaba contar con el completo control del encabezado de Location, pero con esta técnica el atacante necesita tener únicamente un control parcial del encabezado para poder realizarlo.

• Envenenamiento de caché en servidor: En este ataque, el objetivo no es necesariamente contra un usuario en particular, sino que el objetivo del atacante es el servidor de caché. Lo que intentará es contaminar el servidor, haciendo una petición a una página que pueda ser almacenada en caché, pero modificando los encabezados para recibir dos respuestas. El servidor almacenará en caché la segunda respuesta, la cual es completamente controlada por el atacante, y en la siguiente petición que realice cualquier usuario que pase por ese servidor, se le devolverá la página falsa que se encuentra en caché, sin que el atacante necesite volver a realizar acción alguna.

• Secuestro de páginas: Para realizar un secuestro de página, el atacante debe manipular los encabezados de tal manera que sea el mismo atacante quien reciba la respuesta del servidor a una petición del cliente, de manera que si el cliente solicita alguna página con información sensible, el atacante sea quien la reciba, y pueda así tener acceso a esa información.

• Envenenamiento de caché en el navegador: Es un ataque similar al envenenamiento de caché en servidor, pero dirigido específicamente a una víctima en particular. El ataque es semejante también a los ataques de XSS no persistentes 11 , pues el cliente debe acceder a una liga especialmente fabricada, pero a diferencia de estos, el envenenamiento de caché es permanente, pues la página falsa se queda almacenada en el caché del navegador y cada vez que el usuario solicite la página atacada, su navegador le devolverá la página falsa.

5.2 EJEMPLO DE ATAQUE DE DIVISIÓN DE RESPUESTA DE HTTP

Para explicar la forma en que se realizan los ataques de división de respuesta de HTTP, utilizaremos segmentos de código en JSP 12 , en los cuales se realizarán las redirecciones que dan pie al ataque. Antes de iniciar con el código, es importante entender que estos ataques ocurren

11 Ver sección 3.1. 12 JSP: Java Server Pages

35

cuando las aplicaciones no validan las entradas proporcionadas por los usuarios, para evitar que contengan caracteres como CR y LF. La secuencia de los caracteres CR y LF ocasionan que la siguiente instrucción se interprete como un nuevo encabezado. Una doble secuencia de estos caracteres significa una nueva petición.

Las representaciones equivalentes a estos caracteres, son: CR = %0d = \r

LF = %0a = \n

Como ejemplo, utilizaremos una aplicación que manda como parámetro a la aplicación la codificación en la que debe ser desplegada la página. La página en donde se selecciona el tipo de codificación será formulario.jsp, y la página que va a mostrar será contenido.jsp. Al cargar nuestra página, ésta redirige al usuario a una nueva página con la codificación solicitada. El código para realizar esto es el siguiente:

<% response.sendRedirect("/contenido.jsp?encode=" +

request.getParameter("encode")); %>

Esto generaría una respuesta similar a la que se presenta a continuación:

HTTP/1.x 302 Movido temporalmente

Date: Tue, 15 Jan 2008 08:25:42 GMT Location: http://www.servidor.com/contenido.jsp?encode=iso‐8859‐15

Content‐Type: text/html

<html><head><title>302 Movido temporalmente</title></head> <body bgcolor="#FFFFFF">

<p>El documento que ha solicitado se ha movido temporalmente.</p> <p>Ahora está en <a href="http://www.servidor.com/contenido.jsp?encode=iso‐

8859‐15">http://www.servidor.com/contenido.jsp?encode=iso‐8859‐15</a>.</p> </body></html>

La funcionalidad no parece tener ningún problema, pero como se puede observar en el ejemplo, el parámetro de codificación encode está dentro del encabezado de Location. Esto es justamente lo que se busca en este tipo de ataques, pues al tener información de algún parámetro proporcionado por el cliente directamente en el encabezado, se puede introducir cualquier información en los encabezados. Si en este caso, el atacante fabricara una dirección para enviar un parámetro que incluya la secuencia de CRLF, la respuesta cambiaría, como se muestra en el siguiente ejemplo:

36

http://www.servidor.com/forumulario.jsp?encode=algo%0d%0aContent‐

Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent‐ Type:%20text/html%0d%0aContent‐Length:%2019%0d%0a%0d%0a<html>Esta es una página

falsa.</html>

Esto ocasiona que la siguiente respuesta por parte del servidor 13 :

1. HTTP/1.1 302 Movido temporalmente 2.

3. Date: Wed, 24 Dec 2003 15:26:41 GMT 4. Location: http://www.servidor.com/forumulario.jsp?encode=algo

5. Content‐Length: 0 6.

7. HTTP/1.1 200 OK 8. Content‐Type: text/html

9. Content‐Length: 38 10.

11.<html>Esta es una página falsa.</html>

La respuesta de la línea 1 a la 4 es la primera respuesta recibida y contiene una redirección (código 302). En la parte de los encabezados inyectados se incluye en encabezado Content­ Length, el cual indica el tamaño del contenido de la respuesta. En este caso se indica que el tamaño es 0, por lo que no hay contenido.

De la línea 6 a la 10, se encuentra la segunda respuesta con un contenido de 38 bytes. Esta segunda respuesta es la que controla de manera absoluta el atacante, por lo que es la respuesta que puede contener código peligroso. Para explotar esta vulnerabilidad, el atacante debe realizar dos peticiones, la primera en donde genera el ataque y produce dos respuestas y la segunda petición que sería el elemento a contaminar.

Por ejemplo, si en la primera petición se manda la liga del ataque explicada en el ejemplo anterior, y en seguida se solicita un segundo elemento (por ejemplo, documentos.jsp), la víctima interpretaría la primera respuesta (líneas 1 a 4) como la respuesta de su primera petición, posteriormente interpretaría la segunda respuesta (líneas 6 a 10) como respuesta a su petición del elemento documentos.jsp. Si este elemento pudiera ser almacenado en caché (ya sea del servidor o del navegador), la próxima vez que el cliente solicite el elemento documentos.jsp, automáticamente se le mostrará la página falsa.

Es difícil que la víctima se percate del ataque, pues a partir de este momento, a pesar de realizar directamente la solicitud de la página documentos.jsp, tecleando la dirección en su navegador,

13 La numeración no es parte de la respuesta y solamente se incluye como referencia.

37

siempre va a obtener la página falsa. Para quitarlo, necesitaría borrar el caché de su navegador, si éste fuera el envenenado, o contactar a los administradores del servidor de caché para eliminarlo de ahí, lo cual complica bastante la solución. Además de esto, el mismo atacante puede de la misma manera, con un nuevo ataque, quitar el envenenamiento, evitando así cualquier sospecha.

38

6 PROGRAMACIÓN ORIENTADA A ASPECTOS

La programación orientada a aspectos (AOP 14 ) es un paradigma de programación presentado en 1997 por Gregor Kiczales y su equipo de investigación del Xerox PARC 15 [5]. A pesar de ser esta la primera publicación oficial que presenta la AOP, la idea de la orientación a aspectos ya se venía formando desde 1991, con el grupo de trabajo Demeter [16]. En el proyecto Demeter, liderado por Kart Lieberherr, se trabajó sobre la separación entre comportamiento y la estructura del objeto en la programación orientada a objetos, con una técnica llamada “programación adaptativa”.

En la década de los noventa surgieron varios proyectos que intentaban solucionar el problema de la separación de intereses 16 . En la tabla 6.1 se muestran las diversas iniciativas que se tomaron por algunos investigadores en el área para solucionar el problema con diferentes técnicas 17 [17].

La primera definición del concepto de aspecto fue publicada en 1995, también por el grupo Demeter, y se describía de la siguiente forma: Un aspecto es una unidad que se define en términos de información parcial de otras unidades [16]. La colaboración de Lieberherr con Cristina Lopes y Gregor Kiczales llevó a que finalmente surgiera la programación orientada a aspectos, donde la programación adaptativa se considera una parte de la AOP. De acuerdo con Cristina Lopes, el término “programación orientada a aspectos” fue propuesto por Chris Maeda, quien trabajaba también con el equipo en Xerox PARC [17].

14 AOP: Aspect Oriented Programming (Programación orientada a aspectos). 15 PARC: Palo Alto Research Center (Centro de investigación de Palo Alto, ubicado en California). 16 Se utiliza la palabra intereses para sustituir el término en inglés concerns. 17 En el texto original se incluyen las citas a las publicaciones que apoyan cada trabajo.

39

Tabla 6.1 Trabajos sobre la separación de intereses

Técnica Interés

Organización de clases Lieberherr 1994

Sincronización de procesos Watanabe 1990 Lopes 1994 Akşit 1993 Frølund 1993

Reghizzi 1991 Control de localización Okamura 1994 Zeidler 1992

Takashio 1992 Limitantes de tiempo real Akşit 1994 Barbacci 1986

Otros Liskov 1983

Jacobson 1986 Magee 1989

Programación en meta­nivel

Programación adaptativa

Filtros de composición Otros

El concepto de aspecto evolucionó hasta convertirse en lo que define Gregor Kiczales como: Un aspecto es una unidad modular que se disemina por la estructura de otras unidades funcionales. Los aspectos existen tanto en la etapa de diseño como en la de implementación. Un aspecto de diseño es una unidad modular del diseño que se entremezcla en la estructura de otras partes del diseño. Un aspecto de programa o de código es una unidad modular del programa que aparece en otras unidades modulares del programa [18].

De manera más informal podemos decir que los aspectos son la unidad básica de la AOP, y pueden definirse como las partes de una aplicación que describen las cuestiones claves relacionadas con la semántica esencial o el rendimiento. Entre los objetivos que se ha propuesto la programación orientada a aspectos están principalmente el de separar conceptos y el de minimizar las dependencias entre ellos. Con el primer objetivo se consigue que cada cosa esté en su sitio, es decir, que cada decisión se tome en un lugar concreto, con el segundo se tiene una pérdida del acoplamiento entre los distintos elementos.

Entre las ventajas de utilizar la programación orientada a aspectos se encuentran:

• Un código menos enmarañado, más natural y más reducido. • Una mayor facilidad para razonar sobre las materias, ya que están separadas y tienen una

dependencia mínima. • Más facilidad para depurar y hacer modificaciones en el código. • Se consigue que un conjunto grande de modificaciones en la definición de una materia

tenga un impacto mínimo en las otras. • Se tiene un código más reutilizable y que se puede acoplar y desacoplar cuando sea

necesario.

40

6.1 DISPERSIÓN DE CÓDIGO

La dispersión de código existe en numerosas aplicaciones, ya sean orientadas a objetos o no. Un ejemplo típico de esta situación se presenta con el registro de bitácoras, pues al ser necesario dejar rastro de múltiples actividades en diferentes partes de la aplicación, el código para realizar esta acción queda disperso en todas las clases de la aplicación [19]. Este es justamente el ejemplo que presentó Gregor Kiczales para analizar la modularidad de algunos aspectos en el servidor de aplicaciones Tomcat [20]. En la figura 6.1 se muestra un ejemplo de buena modularidad para la coincidencia de patrones de direcciones URL 18 .

Fig. 6.1 Ejemplo de buena modularidad en Tomcat

Sin embargo, en otros aspectos como el registro de bitácoras, la modularidad se pierde y el código se encuentra disperso en todas las clases de la aplicación, como se muestra en la figura 6.2. El problema con este tipo de aspectos es que se dificulta bastante el darle mantenimiento a este tipo de llamadas, pues para cambiarla se necesita modificar prácticamente todas las clases en muchos lugares diferentes.

18 URL pattern matching

41

Fig. 6.2 Ejemplo de dispersión de código en Tomcat

Cada una de las líneas rojas que se muestran en la figura 6.2, son llamadas que realizan algún tipo de registro de bitácoras. Como se puede ver, se encuentran dispersas en toda la aplicación, a diferencia de la figura 6.1 donde la funcionalidad se encuentra concentrada en dos clases. El resultado de esto es que se tiene código redundante, difícil de entender y de cambiar.

En la programación tradicional se acostumbra ir intercalando dentro del código principal aquellos aspectos que no se pueden separar en un objeto. Esto da como resultado clases llenas de código que no tiene nada que ver son su funcionalidad principal. A esto se le conoce como code scattering. Cuando se utiliza la programación orientada a aspectos, la separación de la funcionalidad principal de las clases de otro tipo de intereses es muy sencilla, por lo que permite un mantenimiento y comprensión menos complicados. En la figura 6.3 se presenta un ejemplo de programación tradicional contra una implementación en programación orientada a aspectos.

Fig. 6.3 Comparación entre programación tradicional y AOP

42

Como se puede ver en la figura 6.3, un programa normal contiene las líneas de código de su funcionalidad principal, pero intercaladas entre ellas se agregan también funcionalidades adicionales. En cambio, al utilizar la programación orientada a aspectos, la modularidad de cada funcionalidad se puede apreciar de inmediato. La clase se separa en tres, una que maneja exclusivamente la lógica del negocio y otras dos que manejan aspectos separados. Los aspectos se unirán a la clase principal, pero únicamente en su versión compilada, no en el código fuente.

6.2 INTEGRACIÓN DE ASPECTOS A LA APLICACIÓN

Los aspectos se pueden integrar a la aplicación de dos maneras: en tiempo de compilación y en tiempo de ejecución. La primera ocurre cuando al compilar nuestra aplicación se utiliza un compilador especial que hace la incorporación de los aspectos al código fuente de la aplicación y genera el código ejecutable con los aspectos incorporados. A este compilador especial se le conoce como tejedor de aspectos 19 . En la segunda opción, el servidor de aplicaciones debe tener la facultad de agregar los aspectos justo cuando una clase es llamada. En este caso, antes de realizar la ejecución, se agrega la funcionalidad del aspecto a la clase, sin necesidad de haber realizado una nueva compilación previa para incorporarlo.

En ambos casos se deben definir los puntos de cruce 20 , que es donde se incorporará el código de los aspectos a las clases de la aplicación. Por medio de los puntos de corte 21 , se le dice al tejedor de aspectos qué consejos 22 debe incluir en cada punto de cruce. De esta manera, como se muestra en la figura 6.4, el tejedor de aspectos integra el código original de la aplicación con los aspectos correspondientes para dar salida al código ejecutable que será cargado en el servidor de aplicaciones.

19 Del término en inglés “aspect weaver”. 20 Del término en inglés “jointpoint”. 21 Del término en inglés “pointcut”. 22 Del término en inglés “advice".

43

Fig. 6.4 Proceso de incorporación de aspectos a la aplicación

La manera en que se definen los puntos de corte depende del entorno de desarrollo que se vaya a utilizar. Por ejemplo, AspectJ proporciona una extensión del lenguaje de programación Java, la cual se utiliza para generar los archivos .aj en donde se definen los puntos de corte y los consejos a utilizar en cada punto de cruce [6]. En el caso de JBoss AOP, la definición se hace por medio de un archivo XML en el cual se especifican los puntos de corte y las clases que se harán cargo de manejar las llamadas [7].

Pero antes de realizar la incorporación de los aspectos a la aplicación, se debe identificar qué aspectos son los que la afectan. Cada aplicación convive con diferentes aspectos, y la manera de identificarlos es a través de las necesidades y requerimientos que tiene. Una analogía que sirve para entender la manera en que los aspectos deben ser separados de los requerimientos es el paso de un alo de luz blanca por un prisma, como se muestra en la figura 6.5.

44

Fig. 6.5 Analogía del prisma para separar aspectos

Así como cuando la luz blanca penetra el prisma y éste divide la luz blanca en todos los colores que la componen, de la misma manera se debe realizar el análisis de requerimientos para poder separar cada uno de los intereses que forman parte de la aplicación. Cuando los intereses se deben propagar por toda la aplicación, se les conoce como intereses transversales 23 , y son justamente estos los que debemos separar para evitar que el código quede disperso en toda la aplicación.

La manera en que los aspectos se integran a la aplicación depende de la definición de la intercepción que se haya pedido. Lo primero que se debe realizar es definir en qué partes del código de la aplicación original se debe incorporar cada aspecto. Una vez definido esto, se debe decidir si el consejo del aspecto debe realizarse antes, después o alrededor de la llamada en la aplicación original.

El consejo del aspecto es el código que se va a incorporar a las clases de la aplicación. Si se va a integrar antes, todo el código que lleve el consejo se va a anexar a la clase justamente antes de la llamada que se haya definido. Si se va a integrar después, el código del consejo se llama justamente después de terminar la llamada.

El caso más interesante es cuando el consejo se incorpora alrededor de la llamada. A diferencia de las primeras dos formas, aquí el código envuelve a la llamada y puede incluso eliminarla. Esta opción le permite al aspecto realizar modificaciones a los parámetros que se van a enviar a la llamada para integrar alguna validación previa.

23 Del término en inglés “cross­cutting concerns”.

45

Es importante notar que la programación orientada a aspectos no es un reemplazo para los paradigmas existentes, como la programación orientada a objetos, sino que actúa como un complemento para apoyar en las áreas en donde los paradigmas existentes tienen deficiencias y no pueden ser solucionadas más que parchando el código.

46

7 DESARROLLO Y ATAQUE DE UNA APLICACIÓN WEB VULNERABLE

En la actualidad, las aplicaciones Web son cada vez más utilizadas debido a que es sumamente práctico utilizar el navegador como un cliente ligero sin la necesidad de bajar e instalar software adicional para tener acceso a una gran variedad de herramientas y recursos en un sin fin de sitios. El contenido dinámico de las aplicaciones hace crecer su atractivo y facilita el proceso de actualización, permitiendo a los mismos usuarios colaborar con el contenido de los sitios.

En la figura 7.1 se presentan las partes que generalmente interactúan en una aplicación Web. En un esquema regular, para que una aplicación Web con contenido dinámico funcione, se requiere por lo menos de tres partes:

• Cliente: Es el usuario que entrará a consultar información a la aplicación y en ocasiones tendrá oportunidad de agregar y modificar el contenido de la misma.

• Servidor de aplicaciones Web: Es la instancia que atiende las peticiones del cliente y le muestra el contenido que solicita. En el caso del contenido dinámico, se encarga de hacer las peticiones a las demás instancias y crear el contenido de acuerdo a las solicitudes que haga el cliente.

• Servidor de base de datos: Es la instancia que contiene la información que puede ser utilizada por cualquier aplicación, generalmente sólo se almacena la información que es dinámica en la aplicación.

47

Fig. 7.1 Esquema de interacción de una aplicación WEB

La aplicación fue desarrollada utilizando el modelo vista controlador (MVC), el cual consiste en separar los datos de una aplicación, la interfaz de usuario y la lógica de negocio en tres componentes distintos. Este modelo fue concebido por Trygve Reenskaug en 1979 mientras trabajaba en el proyecto de Smalltalk en Xerox PARC 24 [21].

7.1 SECCIONES DE LA APLICACIÓN WEB

Con la finalidad de realizar pruebas, se desarrolló una aplicación con malas prácticas de programación y sin validaciones de entradas, para que fuera vulnerable a todos los tipos de ataques que se mencionan en este proyecto 25 . La figura 7.2 muestra la pantalla principal de la aplicación, que es la que el usuario ve una vez que se ha autenticado.

24 PARC: Palo Alto Research Center (Centro de investigación de Palo Alto, ubicado en California). 25 Durante el desarrollo del proyecto se contó con el apoyo de asesores extranjeros, por lo que para facilitar el entendimiento de la aplicación, toda la interfaz de usuario se encuentra en inglés.

48

Fig. 7.2 Pantalla principal de la aplicación

Se tomó como idea una tienda de libros en línea, en la que un usuario puede ver el catálogo de libros, poner sus comentarios sobre algún producto y visitar otras tiendas. La aplicación está compuesta por varias secciones:

• Autenticación: Forma de autenticación de usuarios que pide un nombre de usuario y una contraseña para poder acceder a la aplicación. La figura 7.3 muestra la pantalla de autenticación de la aplicación.

Fig. 7.3 Pantalla de autenticación

49

• Registro: Cuando los usuarios no cuentan con un nombre de usuario y contraseña, deberán entrar a la sección del registro, donde podrán crear uno. En la figura 7.4 se muestra la pantalla de registro para crear un nuevo usuario en la aplicación.

Fig. 7.4 Pantalla de registro

• Catálogo: Esta sección muestra al usuario el catálogo de libros en venta y sus precios, así como el último comentario que se haya realizado sobre cada artículo y una liga para ver todos los comentarios. En el mismo catálogo se pueden agregar los artículos al carrito de compras y hacer búsquedas para filtrar los productos. Las búsquedas buscan el contenido de la frase buscada tanto en el título del libro como en la descripción. La figura 7.5 muestra el catálogo de libros con los comentarios más recientes de cada uno, la liga para ver el resto de los comentarios, la cantidad de libros en el carrito de compras y el campo para agregarlos. En la figura 7.6 se puede ver el uso de la búsqueda y los resultados que arroja.

50

Fig. 7.5 Pantalla de catálogo

Fig. 7.6 Resultados de la búsqueda

• Comentarios: Aquí se podrán ver todos los comentarios realizados por los usuarios sobre un libro en especial. Si el usuario lo desea, en esta misma sección podrá agregar sus propios comentarios para que sean vistos por otros usuarios. La figura 7.7 muestra la

51

forma para insertar un comentario y la figura 7.8 muestra el resultado de haber insertado el comentario referente al libro.

Fig. 7.7 Pantalla para agregar comentarios

Fig. 7.8 Pantalla de comentarios insertados por los usuarios

• Carrito de compras: En cualquier momento, el usuario puede revisar el contenido de su carrito de compras, ver el total de artículos que ha seleccionado y la cantidad total a pagar. Una vez revisado el contenido, el usuario puede comprar el contenido de su carrito y finalizas su sesión. La figura 7.9 muestra la pantalla del carrito de compras de un usuario.

52

Fig. 7.9 Pantalla del car rito de compras de un usuario

• Ligas a otras tiendas: Se incluyen ligas a otras tiendas para comparar los precios y complementar las descripciones de los artículos. La aplicación no incluye la liga directa, sino que hace una llamada a sí misma para registrar los accesos a cada liga y luego redirige al usuario a la liga seleccionada. La figura 7.10 muestra la pantalla que contiene las ligas a otras tiendas.

Fig. 7.10 Pantalla con las ligas a otras tiendas

53

Cada una de las secciones está hecha da tal manera que sea fácil demostrar los ataques de inyección de SQL, XSS y HTTP RS. La aplicación es completamente funcional en todas sus secciones y está desarrollada con buenas técnicas de programación, pero sin considerar la seguridad como algo importante. Esta es la situación en la que se encuentran muchas aplicaciones en Internet, las cuales fueron desarrolladas pensando en su funcionamiento y no en la seguridad ni en las consecuencias que podrían existir por no considerarla. Las consultas a la base de datos están de igual manera enfocadas al funcionamiento y no cuidan ciertos aspectos de seguridad que son importantes.

7.2 BASE DE DATOS DE LA APLICACIÓN

Como se comentó en al inicio del capítulo, una aplicación Web con contenido dinámico necesita una base de datos en la cual se debe apoyar para obtener la información que le va a mostrar al usuario. En el caso de la tienda en línea de este proyecto, la base de datos de la aplicación cuenta con cinco tablas en donde almacenará la información para las diferentes secciones. En las tablas 7.1 a la 7.5 se mostrará la estructura de la base de datos.

La tabla de usuarios (Tabla 7.1) contiene la información que proporciona un usuario al darse de alta en la aplicación. En la forma de registro se le solicita su nombre real, su correo, un nombre de usuario y una contraseña para que pueda ingresar al sistema. El identificador del usuario se asigna de manera automática al registrarse. Si el usuario es administrador, el campo admin llevará un valor de 1.

Tabla 7.1 Tabla de usuarios en la base de datos.

Tabla: userinfo (Usuarios) Campo Tipo Descripción

id_user int Identificador del usuario user_name varchar(100) Nombre real del usuario email varchar(100) Correo del usuario login varchar(20) Usuario para entrar al sistema pw varchar(20) Contraseña para entrar al sistema admin int Identifica si el usuario es administrador

La tabla de productos (Tabla 7.2) contiene todos los artículos que están en venta en la tienda. Como la aplicación es únicamente con fines de demostración de ataques, no se incluye un control de inventario y el precio está considerado como un entero, sin contemplar centavos. Se incluye información general del producto, como nombre, descripción y precio, además de una imagen para ilustrar el producto. Cuando el producto se da de baja, el campo de active cambia de 1 a 0.

54

Tabla 7.2 Tabla de productos en la base de datos.

Tabla: product (Productos) Campo Tipo Descripción

id_product int Identificador del producto product_name varchar(100) Nombre del producto description text Descripción del producto price int Precio del producto image varchar(100) Dirección de la imagen del producto active int Indica si el producto está activo

La tabla del carrito de compras (Tabla 7.3) es la que almacena lo que el usuario vaya solicitando, hasta que termine su orden de compra. Al estar almacenado en base de datos, el usuario puede dejar su compra a la mitad y regresar después para terminar de seleccionar sus productos y finalizar su compra. La tabla incluye el identificador del usuario, el del producto y la cantidad que quiere comprar.

Tabla 7.3 Tabla de car rito de compras en la base de datos.

Tabla: cart (Carrito de compras) Campo Tipo Descripción

id_user int Identificador del usuario id_product int Identificador del producto quantity int Número de piezas a comprar

La tabla de comentarios (Tabla 7.4) guarda todos los comentarios que los usuarios realizan sobre un producto. Contiene una relación del usuario, el producto sobre el que comenta, el comentario del usuario y la fecha en la que lo realizó. Se utiliza un campo de fecha con el tipo timestamp para poder ordenar los comentarios por la fecha en que fueron creados y así poder mostrar el último comentario realizado en el catálogo.

Tabla 7.4 Tabla de comentarios sobre los productos en la base de datos.

Tabla: comment (Comentarios sobre productos) Campo Tipo Descripción

id_user int Identificador del usuario id_product int Identificador del producto comment text Comentario del usuario sobre el producto comm_date timestamp Fecha del comentario

55

La tabla de ligas a otros sitios (Tabla 7.5) contiene el listado de sitios a los cuales queremos mandar al usuario para que compare nuestros productos y precios. En la tabla se incluyen el nombre del sitio, su dirección de Internet y una breve descripción de lo que el usuario puede encontrar ahí. Se incluye también un registro de visitas, para saber cuáles son las ligas que más prefieren los usuarios.

Tabla 7.5 Tabla de ligas a otros sitios en la base de datos.

Tabla: link (Ligas a otros sitios) Campo Tipo Descripción

id_link int Identificador de la liga site_name varchar(100) Nombre del sitio url varchar(100) Dirección del sitio en Internet description text Descripción del sitio hits int Número de visitas a la liga

Los tipos que se muestran en las tablas son para una base de datos en MySQL. Esta fue la base de datos que se utilizó para realizar las pruebas de la aplicación pues tiene como ventaja el ser una base de datos gratuita y sencilla de utilizar que cubre todas las necesidades que requiere una aplicación a este nivel.

7.3 VULNERABILIDADES DE LA APLICACIÓN

Como se comentó al inicio del capítulo, y como lo dice el nombre del mismo, la aplicación es vulnerable a los tres ataques ya mencionados. La facilidad de realizar estos ataques es lo que genera una mayor preocupación sobre el problema. A continuación se hará una demostración de cada uno de los ataques en diferentes secciones de la aplicación, documentando con pantallas de la misma los resultados a dichos ataques.

Una de las maneras de ver si la información que estamos enviando está llegando a la aplicación sin ser validada, es mandar entradas que generen errores. Si logramos obtener una pantalla de error al enviar entradas específicas, quiere decir que la información está siendo utilizada tal como la ingresamos, lo que nos da la pauta para ir probando una serie de ataques. Cuando las aplicaciones o los servidores de aplicación no manejan adecuadamente los errores, las pantallas de error pueden mostrar información delicada, como segmentos de las peticiones a las bases de datos, nombres de tablas, campos, etc. En la figura 7.11 podemos ver la pantalla de error que genera la aplicación.

56

Fig. 7.11 Pantalla de er ror de la aplicación

7.3.1. VULNERABILIDADES DE INYECCIÓN DE SQL

La aplicación es vulnerable a ataques de SQL, debido a que las peticiones a la base de datos se construyen a partir de los datos ingresados por el usuario sin tener algún tipo de validación previa que los limpie. La primera vulnerabilidad la encontramos en la pantalla de autenticación, donde podemos brincarnos la validación inyectando una comilla, seguida de una tautología y un comentario. La figura 7.12 nos muestra la inyección realizada en la pantalla de autenticación, mientras que la figura 7.13 nos muestra el resultado de esa inyección.

Fig. 7.12 Inyección de SQL en la autenticación

Fig. 7.13 Ingreso como administrador a la aplicación

Como se puede observar, el resultado de este ataque fue que el usuario ingresó a la aplicación sin proporcionar ningún usuario ni contraseña y además fue autorizado como el administrador del

57

sistema. Esto es algo común en las aplicaciones, pues este ataque lo que ocasiona es que la petición a la base de datos regrese todos los usuarios del sistema, pues la petición queda así:

SELECT id_user, user_name, email, login, pw, admin FROM userinfo

WHERE login = '' or 1=1#' and pw = ''

Todo lo que se encuentre después del signo “#” será ignorado por la base de datos, pues lo considera un comentario. Esto ocasiona que la base de datos busque al usuario con login vacío y la tautología ocasiona que regrese todos los registros de la tabla. Generalmente, el primer usuario que se registra en la aplicación es el administrador, por lo que al regresar todos los usuarios, el primero que toma es al usuario administrador, dándole al atacante los privilegios elevados de este usuario.

Se puede realizar otro ataque con la misma técnica, pero más dirigido, es decir, para ingresar con una cuenta específica sin utilizar la contraseña. Para esto ingresamos a la forma de autenticación el nombre de usuario que queremos utilizar seguido de una comilla y el comentario. La figura 7.14 nos muestra un ejemplo de este ataque.

Fig. 7.14 Inyección de SQL dirigida en la autenticación

Este ataque generaría que la petición a la base de datos se forme con un nombre de usuario, pero eliminando la restricción de la contraseña. La petición que esto generaría sería así:

SELECT id_user, user_name, email, login, pw, admin FROM userinfo

WHERE login = 'toto'#' and pw = ''

Una vez más, el signo “#” ocasiona que la revisión de la contraseña se invalide por lo que el sistema nos da el acceso directo al usuario toto, simplemente con conocer su usuario. En la figura 7.15 se muestra la pantalla de bienvenida para este usuario.

58

Fig. 7.14 Ingreso como usuario a la aplicación

Otro ataque de inyección de SQL que se puede realizar en la aplicación es en el campo de búsquedas. Una consulta normal generaría una petición a la base de datos que buscaría el texto dentro del nombre y la descripción del libro. La petición para encontrar libros sobre “lisph” quedaría como sigue:

SELECT id_product, product_name, description, price, image, active FROM product

WHERE active = 1 AND

( product_name LIKE '%lisph%'

or description LIKE '%lisph%' )

En caso de encontrar algo, nos regresaría el catálogo de libros que coincidan con la búsqueda. En la figura 7.15 se muestra el resultado de una búsqueda normal.

Fig. 7.15 Resultado de una búsqueda normal

59

En este caso, los resultados de la consulta son desplegados en pantalla. Esto puede ser aprovechado por un atacante para consultar otro tipo de catálogos, como por ejemplo el de usuarios. Haciendo uso de la función “UNION” en las peticiones a la base de datos, se pueden unir los resultados de varias peticiones en un mismo juego de registros. Si el atacante utiliza esto en el campo de búsqueda, podría generar un ataque como el que se presenta en la figura 7.16.

Fig. 7.16 Inyección de SQL con UNION en las búsquedas

Para conocer los campos de las tablas se puede ir haciendo un ataque de inyección a ciegas, hasta obtener los datos necesarios, ya sea por errores de la aplicación o por prueba y error del atacante. Esta entrada provocaría que la petición a la base de datos quedara de la siguiente manera:

SELECT id_product, product_name, description, price, image, active

FROM product WHERE active = 1

AND (

product_name LIKE '%x') union select 9, login, pw, 4, 5, 6 from userinfo#%' or description LIKE '%x%'

)

Esta petición buscaría todos los libros que contengan “x” al final de su nombre o descripción (poco probable), pero además anexaría a los resultados todos los registros de la tabla de usuarios, con los campos login y pw (usuario y contraseña). Y esto lo desplegaría en la aplicación como se muestra en la figura 7.17.

60

Fig. 7.17 Usuarios y contraseñas en el catálogo de libros de la aplicación

Como se puede observar en la figura 7.17, en donde debería ir el nombre del libro se muestra en nombre de usuario y en lugar de la descripción aparece la contraseña. Esto hace que la seguridad de todas las cuentas quede vulnerada.

7.3.2. VULNERABILIDADES DE XSS

Los ataques de XSS no van dirigidos hacia la aplicación en sí, están dirigidos a los usuarios que la utilizan. La aplicación es vulnerable a estos ataques cuando toma directamente la información proporcionada por los usuarios sin validarla, para luego mostrarla de alguna manera. Este tipo de situaciones también permiten ataques de inyección de HTML, que aunque no son tan peligrosos, permiten facilitar otros ataques como los de inyección de SQL y XSS. Un ejemplo de esta vulnerabilidad se presenta cuando ingresamos información en una forma y al contestar la petición, nos muestra de nuevo la información que ingresamos.

Un atacante podría aprovecharse de esto, por ejemplo, para alterar los tamaños de los campos, si requiriera más caracteres para enviar su ataque. En la figura 7.18 podemos ver cómo se puede inyectar código HTML en el campo de búsqueda, y en la figura 7.19 vemos el resultado de la inyección. Si se genera una dirección URL con una inyección de HTML integrada, podríamos generar un formulario falso para un usuario dentro de un sitio legítimo, siempre y cuando el usuario no sospeche de la dirección.

61

Fig. 7.18 Inyección de HTML en el campo de búsqueda

El campo de búsqueda está formado por código HTML de la siguiente manera:

<input type="text" name="criteria" id="criteria" value="" size="50">

Al enviar el texto te la figura 7.18, la aplicación incluye la información enviada en el atributo “value” de la etiqueta para mostrarlo de nuevo al usuario, por lo que queda de la siguiente forma:

<input type="text" name="criteria" id="criteria" value="" size="100">"

size="50">

Esto da como resultado que el navegador interprete la secuencia de información de una forma alterada, tal como lo muestra la figura 7.19.

Fig. 7.19 Resultado de la inyección de HTML

Al hacer una inyección tan sencilla, alteramos el tamaño del campo, permitiendo así la captura de más caracteres para cualquier otro ataque. Pero así como se alteró el tamaño, se pueden agregar contenido a la página, formularios, etc. Para propagar el ataque, al igual que con los ataques de XSS no persistentes, necesitamos promocionar alguna liga que contenga el ataque, lo que en ocasiones hace sospechar a las víctimas y dificulta su resultado. Pero cuando la aplicación guarda información que el usuario proporciona y la muestra a todos los usuarios, el ataque puede llegar sin que los usuarios se den cuenta.

En la aplicación, al mostrar el catálogo de libros, muestra también el último comentario capturado por algún usuario. Al ser esta la primera pantalla que ven los usuarios al ingresar al sistema, proporciona el ambiente óptimo para un ataque de XSS persistente. Un ejemplo sencillo, sería capturar un comentario que contenga código en JavaScript, como se muestra en la figura 7.20.

62

Fig. 7.20 Captura de un comentario para un ataque de XSS

El agregar este comentario a un libro, cada vez que algún usuario abra el catálogo de la aplicación, le aparecerá el mensaje “Vulnerabla a XSS”, como se muestra en la figura 7.21. Sin embargo, este código no tiene que ser capturado por completo en el cuadro del comentario. El código puede ser cargado desde un sitio externo, simplemente añadiendo el atributo “src=dirección” en la etiqueta <script>. Con esto podemos hacer que el ataque vaya cambiando al ir modificando el archivo externo.

Fig. 7.21 Resultado de un ataque de XSS simple

El código en el sitio externo puede ser tan complejo como el atacante quiera, pues ya no tiene límite de ningún tipo. Si se descubre alguna vulnerabilidad en los navegadores, utilizando JavaScript, el atacante puede modificar su archivo para explotarla, sin tener que agregar un nuevo comentario al sitio. Con esto le permitiría al atacante tener acceso incluso a los sistemas operativos de los usuarios, no solamente a su navegador.

63

7.3.3. VULNERABILIDADES DE HTTP RESPONSE SPLITTING

Para que pueda existir una vulnerabilidad de división de respuesta de HTTP, es necesario que la aplicación utilice información que le pueda proporcionar el usuario para generar algún encabezado de HTTP. Un ejemplo típico de esto y que es muy utilizado en sitios importantes en Internet (como Google y Yahoo!), es redirigir a un usuario de una dirección a otra. La forma en que lo hacen es enviando primero al usuario a una página local del sitio para de ahí redirigirlos al sitio que pretenden visitar. El objetivo de este tipo de comportamientos es, por lo general, registrar el número de visitas de cada liga para realizar análisis posteriores.

En el caso de la aplicación de prueba, se tienen una serie de ligas a sitios que también venden libros y se registran los clicks que se realizan a cada liga, por lo que al mostrar los sitios, no se muestra una liga directamente a los sitios, sino que pasan primero por una página local de la aplicación que los redirige. La dirección de destino llega como parámetro a la aplicación y la toma para crear un encabezado de HTTP que le indicará al navegador a dónde dirigirse.

La figura 7.22 muestra la liga en la aplicación al sitio de Amazon, cuando un usuario da clic en la liga que dice “Click here”, no será llevado a la dirección de Amazon, sino a una dirección de la misma aplicación:

http://localhost:8888/virtuaStore/?act=goto&url=http://amazon.com

Fig. 7.22 Liga de la aplicación a un sitio real

Sin embargo, para el usuario esto es transparente, pues al dar clic en la liga, la siguiente pantalla que ve es justamente la pantalla de Amazon, como lo muestra la figura 7.23.

64

Fig. 7.23 Resultado de consultar una liga normal

Este tipo de redirecciones se realizan con un código de respuesta “HTTP/1.x 302 Movido temporalmente”, que indica una redirección, como se muestra en la siguiente secuencia de comunicación entre el navegador y los servidores:

http://localhost:8888/virtuaStore/?act=goto&url=http://www.amazon.com

GET /virtuaStore/?act=goto&url=http://www.amazon.com HTTP/1.1 Host: localhost:8888

User‐Agent: Mozilla/5.0 (X11; U; Linux i686; en‐US; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0.12 Accept:

text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8 ,image/png,*/*;q=0.5

Accept‐Language: es‐ar,es;q=0.8,en‐us;q=0.5,en;q=0.3 Accept‐Encoding: gzip,deflate

Accept‐Charset: ISO‐8859‐1,utf‐8;q=0.7,*;q=0.7 Keep‐Alive: 300

Connection: keep‐alive Cookie: JSESSIONID=C465A6C79E3385308DDC29C04730FDAF

HTTP/1.x 302 Movido temporalmente

Server: Apache‐Coyote/1.1 Location: http://www.amazon.com

Content‐Type: text/html Content‐Length: 0

Date: Tue, 26 Feb 2008 14:44:22 GMT

65

Esta petición le avisa al navegador que la dirección que solicitó fue movida a la nueva dirección, en este caso http://www.amazon.com, lo que genera una segunda petición, ahora al nuevo sitio que le fue indicado:

http://www.amazon.com/

GET / HTTP/1.1

Host: www.amazon.com User‐Agent: Mozilla/5.0 (X11; U; Linux i686; en‐US; rv:1.8.1.12) Gecko/20080207

Ubuntu/7.10 (gutsy) Firefox/2.0.0.12 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8

,image/png,*/*;q=0.5 Accept‐Language: es‐ar,es;q=0.8,en‐us;q=0.5,en;q=0.3

Accept‐Encoding: gzip,deflate Accept‐Charset: ISO‐8859‐1,utf‐8;q=0.7,*;q=0.7

Keep‐Alive: 300 Connection: keep‐alive

Cookie: session‐id=102‐2391174‐6965764; session‐id‐time=1204790400l; ubid‐ main=105‐2746321‐3129340; session‐

token=weK8MoklUtO3Te0IybmQ9Ds1fgqBkThemmuDIMdn9hxZKOMGCqUXVHXOiApqMF2wbtE1JK8AJ OG6Htqy/UjaVxOGDnBFR+W4G0oWGJMP1QpG2cat6+n6p5VC8yF8KaWlfso6VjuyGQ5HA1TAQc3zLFkH

wV3g3yUnp2j3AjjmCYBjY14aapKS4MDkzR8wlKA2zKnz1UDyTuM=

HTTP/1.x 200 OK Date: Tue, 26 Feb 2008 14:44:18 GMT

Server: Server Set‐Cookie: skin=noskin; path=/; domain=.amazon.com; expires=Tue, 26‐Feb‐2008

14:44:18 GMT x‐amz‐id‐1: 0A85RCH4P2JW46247CMS

x‐amz‐id‐2: HX2KNW77DSK/vcgSq02/TNxYDDSywL/p Vary: Accept‐Encoding,User‐Agent

Content‐Encoding: gzip Content‐Type: text/html; charset=ISO‐8859‐1

Transfer‐Encoding: chunked

Este tipo de acciones también pueden ser aprovechadas por un atacante, para lo que debería fabricar una liga que contenga el ataque de división de respuesta de HTTP. En las figuras 7.24 y 7.25 se muestra el resultado de que un usuario utilice la siguiente liga fabricada con un ataque de este tipo:

http://localhost:8888/virtuaStore/?act=goto&url=%0D%0AContent‐

Type:%20text/html%0D%0A%0D%0A%3Cdiv%20id= 'x'%3E %3Cdiv%20id='y'%3E%3Cscript%20src='file.js'%3E%3C/script%3Ehttp://www.algo.com

66

La liga contiene antes de la dirección de Internet (www.algo.com), el código de inyección de encabezados que a su vez llama a un código de JavaScript (file.js) que puede hacer cualquier cosa con el contenido como se ve en las figuras.

Fig. 7.24 Mensaje en la aplicación ocasionado por un ataque de HTTP RS

Debido al contenido del código, al dar clic en el botón “OK”, el contenido de la página cambia a lo que se muestra en la figura 7.25.

Fig. 7.25 Cambio del contenido con JS en un ataque de HTTP RS

Como se puede notar en ambas figuras, la dirección sigue siendo la de la aplicación, a pesar de haber utilizado una redirección, por lo que para el cliente, cualquier contenido que esté ahí sigue perteneciendo a la misma aplicación. El cliente no tiene por qué saber que la liga que visitó tenía que redirigirlo a otro sitio. Esto puede engañar a los usuarios pidiéndoles datos confidenciales con la confianza que le tienen al sitio que están visitando, sin que se percaten que los datos serían enviados a un sitio malicioso.

67

El navegador es engañado por la inyección de los encabezados. Algunos navegadores servidores de aplicación no obedecen la instrucción de la redirección, a menos que el encabezado de Location contenga una dirección válida, por lo que se agrega al final la dirección de un sitio cualquiera (en este caso http://www.algo.com). La secuencia de comunicación ocurre de la siguiente manera:

http://localhost:8888/virtuaStore/?act=goto&url=%0AContent‐

Type:text/html%0A%0A%3Cdiv%20id='x'%3E%3Cdiv%20id='y'%3E%3Cscript%20src='file.j s'%3E%3C/script%3Ehttp://www.test.com

GET /virtuaStore/?act=goto&url=%0AContent‐

Type:text/html%0A%0A%3Cdiv%20id='x'%3E%3Cdiv%20id='y'%3E%3Cscript%20src='file.j s'%3E%3C/script%3Ehttp://www.test.com HTTP/1.1

Host: localhost:8888 User‐Agent: Mozilla/5.0 (X11; U; Linux i686; en‐US; rv:1.8.1.12) Gecko/20080207

Ubuntu/7.10 (gutsy) Firefox/2.0.0.12 Accept:

text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8 ,image/png,*/*;q=0.5

Accept‐Language: en‐us,en;q=0.5 Accept‐Encoding: gzip,deflate

Accept‐Charset: ISO‐8859‐1,utf‐8;q=0.7,*;q=0.7 Keep‐Alive: 300

Connection: keep‐alive Cookie: JSESSIONID=7f00010122b8c669d020fa70434bb005d393af3898b8;

HTTP/1.x 302 Movido temporalmente

Date: Tue, 26 Feb 2008 16:55:01 GMT Server: Apache‐Coyote/1.1

Content‐Location: http://localhost:8888/virtuaStore/Store Connection: Keep‐Alive

Keep‐Alive: timeout=15, max=100 Content‐Type: text/html

Lo que resulta, ya interpretado por el navegador, en el contenido HTML que se envía como parámetro y que a su vez carga el código de JavaScript y modifica la página, como lo muestran las figuras 7.24 y 7.25.

68

7.4 UNA ALTERNATIVA EFICIENTE PARA CORREGIR LAS VULNERABILIDADES

Las vulnerabilidades presentadas en este capítulo se deben a las malas prácticas de programación que tienen los desarrolladores y que al diseñar la aplicación no se piensa en la seguridad, por lo tanto se pasan por alto algunas medidas y se confía demasiado en los usuarios. No se hacen las validaciones debidas en la información que se provee y eso provoca que la aplicación quede insegura y vulnerable a una serie de ataques como se ha demostrado.

Para poder corregir una aplicación existente se deben identificar todos los posibles puntos vulnerables, corregirlos y volver a probar, con la desventaja de que al arreglar un problema podríamos estar creando uno nuevo. De igual forma, si la aplicación crece y se le agregan nuevos módulos, no se puede estar seguro de que los nuevos módulos no volverán a tener las vulnerabilidades ya arregladas, por lo que el mantenimiento de las aplicaciones, cuidando la seguridad, se vuelve cada vez más difícil.

Se requiere de una alternativa eficiente que, sin importar los cambios que sufra la aplicación, pueda proteger siempre cada uno de los módulos, nuevos y viejos, sin necesidad de tener que revisar de nuevo toda la aplicación en cada actualización. Debe además ser flexible y fácil de mantener, de manera que se puedan hacer cambios rápidos que impacten en todos los módulos y que pueda ser configurable para cubrir las diferentes necesidades de varias aplicaciones, utilizando el mismo modelo.

Con la descripción anterior, la alternativa ideal suena como algo demasiado complejo, casi imposible de obtener, pero en la realidad no lo es. La programación orientada a aspectos nos provee con todas las bases necesarias para realizar una solución que cubra todos esos requisitos. Al funcionar como una capa que envuelve a la aplicación, no importa qué tanto vayan cambiando y creciendo los módulos de la aplicación, ésta sigue estando contenida dentro de la capa que la envuelve y por lo tanto sigue protegida.

Utilizando la programación orientada a aspectos, solamente es cuestión de definir las reglas para identificar los puntos vulnerables y así establecer los comportamientos adecuados para asegurarnos de que no puedan ser explotados. Una vez terminado esto, tendremos solamente un punto que mantener, en donde estaría concentrada toda la funcionalidad referente a la seguridad, por lo que el mantenimiento se facilita mucho más y los puntos de falla no vuelven a aparecer con cada actualización de la aplicación.

69

8 APROSEC

AProSec es un aspecto creado para proteger aplicaciones Web contra las tres principales vulnerabilidades que existen en este momento: inyección de código SQL, XSS y la división de respuesta de HTTP. Su nombre proviene de la abreviación en inglés de “Aspect for Programming Secure Web Applications” y su objetivo es cubrir una aplicación existente con una capa de seguridad que le permita continuar con su operación normal de manera casi transparente.

Está compuesto por tres partes principales:

• Configuración del aspecto: El administrador de la aplicación puede modificar el archivo de configuración para determinar qué validaciones desea realizar en cada aplicación.

• Consejos (Advice): Es el código que va a ser agregado a los puntos de unión y contiene el proceso de validación.

• Puntos de corte (Pointcut): Define los consejos que se van a aplicar a cada punto de unión para que se haga la inserción de código.

La integración del aspecto a la aplicación puede ser hecha de dos maneras, en tiempo de compilación y en tiempo de ejecución. La forma de realizar cada una, así como la definición de los puntos de corte, depende del entorno en el que vaya a hacer. Durante el desarrollo del proyecto se hicieron pruebas con dos entornos de trabajo, el primero utilizando AspectJ y el segundo con JBoss AOP.

Los puntos de cruce y los consejos son los mismos, independientemente del entorno que se vaya a utilizar. La diferencia entre las implementaciones es la forma de definir los puntos de corte, en AspectJ se usa una extensión del lenguaje de programación Java, mientras que en JBoss AOP esto se hace por medio de un archivo XML. En la figura 8.1 se puede observar la manera en que la aplicación interactúa de forma normal, mientras que en la figura 8.2 se ve cómo se agrega AProSec a la aplicación como una capa que ahora valida las entradas y salidas a la aplicación.

Cuando una aplicación recibe una petición de algún cliente, la atiende directamente y si no tiene la programación adecuada para validar la información que le están proporcionando, los ataques

70

llegan directamente a ella. Si esta información es utilizada para realizar una consulta a la base de datos, entonces la misma aplicación reenvía el ataque al servidor de base de datos, el cual solamente interpreta la petición y devuelve el resultado. Este es el ambiente inseguro en el que las aplicaciones operan, tal como lo muestra la figura 8.1, confiando plenamente en que la implementación fue realizada correctamente.

Fig. 8.1 Interacción de una aplicación Web normal

Para evitar que la aplicación quede expuesta a los ataques, le agregamos una capa de seguridad con el aspecto AProSec, como se puede ver en la figura 8.2, de manera que las peticiones que los clientes le generan tienen que ser validados antes de ser utilizados por la aplicación. Cuando se envía una petición a la base de datos, esta también es interceptada y validada, para evitar que la aplicación reenvíe los ataques al servidor de base de datos. Finalmente, cada vez que la aplicación realiza una redirección, se intercepta y valida la llamada para cuidar la respuesta que se le va a mandar al navegador del cliente.

La única petición que nos interesa validar entre los clientes y la aplicación es el paso de parámetros, que es donde los clientes le proporcionan información a la aplicación. Aquí se valida que la información proporcionada no contenga etiquetas inválidas de HTML (como la etiqueta <script> utilizada para cargar código ajeno a la aplicación en los clientes) ni tampoco atributos dentro de una etiqueta válida que puedan hacer referencia a algún código en JavaScript.

Se puede validar también el uso de comillas y apóstrofes, utilizados para algunos ataques. En los datos enviados por los usuarios también se sustituyen algunos caracteres para evitar la inyección de HTML. De esta forma podemos asegurar que los parámetros que mande el usuario no causarán daño a la aplicación, a la base de datos ni a los demás usuarios.

71

Las peticiones a la base de datos también deben ser revisadas, para evitar otro tipo de ataques. A pesar de que en los parámetros de los usuarios ya se puede validar el uso de comillas, hay ataques a la base de datos que no necesitan de éstas, por ejemplo en el caso de campos numéricos. Por esto, en las peticiones a la base de datos se busca validar que la información enviada no contenga cosas anormales, como comentarios o tautologías. Si al revisar la petición se encuentra algo extraño, la petición se envía vacía, evitando así que llegue el ataque.

Fig. 8.2 Interacción de una aplicación protegida con AProSec

Finalmente, también se interceptan las redirecciones que la aplicación manda al cliente, para evitar la inyección de encabezados. Cada vez que la aplicación va a realizar una redirección, se revisa la dirección a la que el cliente va a ser enviado y se eliminan las entradas de CRLF 26 que puedan existir, de manera que el navegador del cliente no vaya a interpretar la dirección con caracteres peligrosos.

26 CRLF: Carriage Return Line Feed.

72

8.1 CONFIGURACIÓN DEL ASPECTO

AProSec puede ser configurado por medio de un archivo XML que contenga las validaciones a considerar para cada aplicación. En el archivo se deben especificar qué validaciones realizar y qué etiquetas de HTML son permitidas para la aplicación (en caso de existir alguna). El archivo de configuración tiene la siguiente estructura:

<?xml version="1.0"?> <!DOCTYPE validator [

<!ELEMENT validator (validateQuotes, validateApost, validateSQLInj, validateXSS, validateHRS, validTag*)>

<!ELEMENT validateQuotes (#PCDATA)> <!ELEMENT validateApost (#PCDATA)>

<!ELEMENT validateSQLInj (#PCDATA)> <!ELEMENT validateXSS (#PCDATA)>

<!ELEMENT validateHRS(#PCDATA)> <!ELEMENT validTag (#PCDATA)>

<!ELEMENT logging (#PCDATA)> ]>

En cada uno de los elementos del archivo se define si la validación debe hacerse o no. Se pueden definir archivos de configuración globales, que abarquen a todas las aplicaciones corriendo en el mismo servidor, o locales, que se consideran solamente para el contexto de la aplicación en donde se encuentra. En caso de existir un archivo global y uno local, se considera únicamente el archivo local de la aplicación. Los elementos que componen el archivo de configuración son:

• validator: Elemento raíz del archivo, el cual contiene a todos los elementos de configuración.

• validateQuotes: Valida la existencia de comillas dobles ( " ) dentro de un parámetro enviado por el usuario. Si la opción está habilitada, cada vez que se reciba un parámetro de HTTP, ya sea por medio de una forma o desde la dirección URL de la aplicación, el aspecto agregará a las comillas dobles una diagonal invertida que las anteceda, para que sirva como carácter de escape, convirtiendo cada ocurrencia de " por \", dejando de esta manera las comillas como parte del texto. Esta opción lleva implícita una validación previa que reemplaza las ocurrencias de \" ya existentes por \\\". La razón de esta última sustitución es para evitar que un atacante pueda aprovechar la validación simple y que al capturar \" y sea reemplazado por \\", dejando entonces la diagonal invertida como texto y no como carácter de escape para las comillas dobles.

• validateApost: Valida la existencia de comilla simple o apostrofe ( ' ) dentro de un parámetro enviado por el usuario. Si la opción está habilitada, cada vez que se reciba un parámetro de HTTP, ya sea por medio de una forma o desde la dirección URL de la

73

aplicación, el aspecto agregará a la comilla una diagonal invertida que las anteceda, para que sirva como carácter de escape, convirtiendo cada ocurrencia de ' por \', dejando de esta manera la comilla como parte del texto. Esta opción lleva implícita una validación previa que reemplaza las ocurrencias de \' ya existentes por \\\'.

• validateSQLInj: Valida las peticiones a la base de datos para evitar que se manden comentarios, tautologías o caracteres de punto y coma antes de finalizar el texto de la petición. Si la opción está habilitada, cada vez que se realice una llamada a la base de datos, el texto es revisado por el aspecto. Si la petición contiene comentarios, tautologías o caracteres de punto y coma, se elimina todo el texto de la petición para que no ejecute nada y regrese una respuesta vacía. Esto ocurre siempre y cuando las coincidencias se encuentren como parte de las instrucciones a la base de datos y no del texto de algún valor.

• vaildateXSS: Valida la información enviada por el usuario para evitar ataques de XSS. Si la opción está habilitada, cada vez que se reciba un parámetro de HTTP, ya sea por medio de una forma o desde la dirección URL de la aplicación, la información será validada y se transformarán todas las etiquetas de HTML que no sean permitidas, y las etiquetas permitidas serán convertidas en etiquetas seguras (explicadas más adelante). Se eliminará cualquier código o llamada de JavaScript que se encuentre en las etiquetas válidas.

• validateHRS: Valida que la dirección a la que será redirigido un cliente no contenga inyección de encabezados. Si la opción está habilitada, cada vez que se vaya a realizar una redirección, el aspecto revisará la dirección que contiene la llamada. El aspecto eliminará cualquier ocurrencia de CR o LF que encuentre en la dirección, evitando que se hagan las inyecciones de encabezados.

• validTag: Esta opción indica si el aspecto debe permitir la entrada de alguna etiqueta de HTML. Debe existir una entrada de esta opción por cada etiqueta que se quiera aceptar. Será responsabilidad del administrador habilitar el uso de algunas etiquetas que puedan ser utilizadas por los usuarios (generalmente etiquetas de estilo como negritas o subrayado y etiquetas de ligas a otras páginas). Incluso cuando se permita el uso de algunas etiquetas, éstas serán revisadas por el aspecto y convertidas en etiquetas seguras.

• logging: Esta opción indica si el aspecto debe generar un registro por cada irregularidad que encuentre. En el contenido de la opción se debe poner la ruta completa al archivo en donde se irán generando los registros.

Para la configuración del aspecto, todos los valores de los elementos son iniciados como verdaderos por defecto, es decir, si no se incluye un archivo de configuración o si dentro del archivo no hay algún elemento, la validación de ese elemento siempre se realiza, con excepción del atributo validTag que existe únicamente cuando se permiten algunas etiquetas de HTML y del

74

atributo logging, que al estar ausente indica que no se generarán registros. Para habilitar explícitamente una opción, el valor del elemento debe ser “TRUE” (sin importar mayúsculas y minúsculas). Cualquier otro valor que contenga el elemento, deshabilita la validación. El orden de los elementos no es considerado.

Un archivo de configuración de ejemplo sería el siguiente:

<validator>

<validateQuotes>false</validateQuotes> <validateSQLInj>false</validateSQLInj>

<validateApost>true</validateApost> <validateXSS>TRUE</validateXSS>

<validateHRS>TruE</validateHRS> <validTag>a</validTag>

<validTag>b</validTag> <validTag>br</validTag>

<validTag>img</validTag> <logging>/var/log/aprosec/virtuaStore.log</logging>

</validator>

En este caso, todas las validaciones quedarían activadas, con excepción de la validación de inyección de SQL y las comillas dobles. Además, la aplicación puede aceptar las etiquetas <a>, <b>, <br> y <img>. Cada vez que el aspecto encuentre alguna irregularidad y deba realizar una transformación, agregará una línea al archivo virtuaStore.log indicando el lugar y la fecha y explicando el motivo y la transformación realizada.

8.2 CONSEJO DE APROSEC

El consejo (advice) de AProSec está compuesto por tres validaciones principales:

• Parámetros de las peticiones de HTTP de los clientes: o java.sql.Statement.addBatch(String) o java.sql.Statement.execute(String) o java.sql.Statement.executeQuery(String) o java.sql.Statement.executeUpdate(String)

• Peticiones de JDBC al servidor de base de datos: o javax.servlet.http.HttpServletRequest.getParameter(String)

75

• Instrucciones de redirección de la aplicación a otro sitio: o javax.servlet.http.HttpServletResponse.sendRedirect(String)

En el caso de los parámetros de los clientes, se valida que no exista inyección de código ni etiquetas HTML inválidas. Cada vez que el aspecto encuentra una etiqueta, revisa si la etiqueta debe o no ser aceptada en la aplicación. En caso de no existir como una etiqueta válida en el archivo de configuración, se cambiarán los caracteres de < y > por sus correspondientes códigos de HTML &lt; y &gt; respectivamente. Con esta sustitución las etiquetas ya no serán interpretadas como tal por el navegador y serán presentadas como texto.

En caso de que la etiqueta haya sido agregada al archivo de configuración como una etiqueta válida, ésta será transformada en etiqueta segura y los atributos de la etiqueta serán revisados para evitar que se hagan llamadas de código y se eliminarán también todos los atributos de interacción (toda la familia de on* como onClick, onMouseOver, etc.).

Ninguna etiqueta puede contener como valor de algún atributo los textos “ javascript:” , “vbscript:” o “tcl:” (hay que notar que todos terminan con dos puntos ‘:’), para evitar ataques como <img src="javascript:alert('Oops!');">. Para estas revisiones se utilizan expresiones regulares que identifican las coincidencias sin importar el uso de mayúsculas y minúsculas, incluye espacios, tabuladores y saltos de línea y finalmente considera también la existencia o ausencia de comillas dobles y simples, de tal forma que todos los siguientes ejemplos serían detectados por el aspecto:

1) <img scr= "jaVas CrIpt:alert('Error!');">

2) <a href="#" oncLick = 'alert("Error!");'>

3) <a href="#" oNcLicK

="alert('Error!');">

4) <a href="#" ONclick=alert('Error!')>

*Nota: Los espacios y saltos de línea fueron agregados intencionalmente para mostrar los ejemplos.

Considerando el archivo de configuración de ejemplo de la sección 8.1, en la tabla 8.1 se presentan ejemplos de entradas de información y la manera en que serían procesadas por el aspecto. Como se puede observar en la tabla, las etiquetas que no se encuentren dentro del archivo de configuración son transformadas para que el navegador las interprete como texto y no como etiquetas. Las que sí están en el archivo son validadas para evitar el uso tanto de los atributos como de los valores en los atributos que puedan realizar alguna llamada a código en JavaScript, lo que podría representar un riesgo para los usuarios.

76

Tabla 8.1 Ejemplos de validaciones utilizando AProSec

Entradas Salidas Comentarios

Una palabra <u>subrayada</u>

Una palabra &lt;u&gt;subrayada&lt;/u& gt;

La etiqueta <u> no es válida, por lo que se transforma a texto de HTML.

Esta es <a href="#" onClick="alert('Thank you!');">una liga</a>.

Esta es <a href="#">una liga</a>.

La etiqueta <a> sí es válida y se respeta, pero el parámetro "onClick" no se permite, por lo que es eliminado de la etiqueta.

<img src="javascript: alert('Oops!');">

<img src="">

La etiqueta <img> sí es válida y se respeta, pero el valor del parámetro "src" tiene una llamada inválida de JavaScript , la cual es eliminada.

' or 1=1# \' or 1=1#

La opción para validar apóstrofes está activada, por lo que la comilla se escapa con una diagonal invertida.

En las peticiones a la base de datos se valida que no existan tautologías, comentarios ni puntos y comas. Se revisan todas las condiciones en las peticiones a la base de datos y en caso de encontrar tautologías, comentarios o puntos y coma, el texto de la petición se elimina por completo, mandando una petición vacía a la base de datos que no debería regresar ningún registro ni alterar el contenido de las tablas. Al buscar tautologías, se buscan comparaciones como:

• 'valor' = 'valor' • número = número (Ej. 1=1) • 'valor' != 'valor' • número != número (Ej. 0!=0) • 'valor' <> 'valor' • tabla1.campo1 = tabla1.campo1

Finalmente en las instrucciones de redirección se valida que las direcciones no contengan saltos de línea que permitan la inyección de encabezados. Se buscan y eliminan todas las ocurrencias de CR y LF que se encuentren en las direcciones antes de redirigir al usuario, cambiando una entrada como esta:

http://www.prueba.com%0d%0aContent‐Length:

%200%0d%0a%0d%0aLocation:%20http://www.ataque.com

77

Por una dirección segura, que no ocasionará una doble respuesta, como esta:

http://www.prueba.comContent‐Length:%200Location:%20http://www.ataque.com

8.3 INTEGRACIÓN DE APROSEC CON ASPECTJ

AspectJ es una extensión para el lenguaje de programación Java, que permite el manejo de aspectos en el desarrollo de aplicaciones. Fue creado por el mismo equipo al que se le acredita la concepción de la programación orientada a aspectos, Gregor Kiczales y su equipo de trabajo en Xerox PARC [6]. De todas las opciones que actualmente se utilizan para el desarrollo de aplicaciones con programación orientada a aspectos, AspectJ es la que se utiliza con mayor frecuencia.

Existen diversas opiniones con respecto a la manera en que AspectJ realiza el manejo de aspectos. Algunos desarrolladores no están de acuerdo en la manera en que AspectJ integra una nueva semántica al lenguaje de programación Java, y prefieren otras alternativas que utilicen Java puro.

La definición de los puntos de corte se realiza utilizando la extensión al lenguaje Java, en archivos con extensión .aj [22]. La definición para AProSec, utilizando AspectJ queda de la siguiente manera:

public aspect AProSec

pointcut dbWrite(String query): (

call(* java.sql.Statement.addBatch(String)) || call(* java.sql.Statement.execute(String)) ||

call(* java.sql.Statement.executeQuery(String)) || call(* java.sql.Statement.executeUpdate(String))

) && args(query);

pointcut getParameter():

call(String javax.servlet.http.HttpServletRequest.getParameter(String));

pointcut sendRedirect(String url): call(String javax.servlet.http.HttpServletResponse.sendRedirect(String))

&& args(url);

Object around(String query) : dbWrite(query)

78

String validQuery = aprosec.Validator().validateSQLInj(query);

return proceed(validQuery);

String around() : getParameter()

return new aprosec.Validator().validate(proceed());

Object around(String url) : sendRedirect(url)

String validURL = aprosec.Validator().validateHRS(url); return proceed(validQuery);

En el archivo se especifican las llamadas que se deben interceptar y las acciones a tomar en cada una de las llamadas. En la intercepción de la llamada getParameter(), los parámetros llamada no requiere ser modificada, por lo que la declaración del punto de corte no lleva parámetros, lo que se desea modificar es el resultado de obtener los parámetros del cliente y por eso el regreso es el resultado de validar esos valores. En las llamadas a la base de datos y la redirección, lo que importa es el contenido de la llamada y no el resultado, por lo que esas dos intercepciones sí llevan parámetros y lo que se envía a la llamada es el resultado de la validación de esos parámetros.

8.4 INTEGRACIÓN DE APROSEC CON JBOSSAOP

JBoss AOP es un ambiente de desarrollo para programación orientada a aspectos, utilizando 100% Java puro [7]. Puede ser utilizado únicamente como ambiente de programación o en conjunto con el servidor de aplicaciones JBoss. Tiene la facilidad de hacer la integración de los aspectos tanto en tiempo de compilación como en tiempo de ejecución [23].

La principal ventaja de utilizar la integración en tiempo de ejecución es que la aplicación no requiere de ninguna manipulación previa para instalarla en el servidor de aplicaciones. La desventaja de esta integración es que consume más recursos durante la ejecución de la aplicación. Al utilizar la integración en tiempo de compilación, se debe recompilar la aplicación utilizando el aspecto, antes de instalarla en el servidor de aplicaciones, pero no requiere ningún procesamiento adicional durante su ejecución.

La configuración de los puntos de corte utilizando JBoss AOP se realiza en un archivo de XML que contiene la definición de los puntos y las acciones a tomar. El archivo utilizado para AProSec tiene la siguiente definición:

79

<aop>

<bind pointcut="call(java.lang.String

$instanceofjavax.servlet.http.HttpServletRequest ‐> getParameter*(java.lang.String))">

<interceptor class="aprosec.ParameterInterceptor"/> </bind>

<bind

pointcut="call(* $instanceofjava.sql.Statement ‐> addBatch*(java.lang.String))">

<interceptor class="aprosec.QueryInterceptorQuery"/> </bind>

<bind

pointcut="call(* $instanceofjava.sql.Statement ‐> execute*(java.lang.String))">

<interceptor class="aprosec.QueryInterceptor"/> </bind>

<bind

pointcut="call(* $instanceofjava.sql.Statement ‐> executeQuery*(java.lang.String))">

<interceptor class="aprosec.QueryInterceptor"/> </bind>

<bind

pointcut="call(* $instanceofjava.sql.Statement ‐> executeUpdate*(java.lang.String))">

<interceptor class="aprosec.QueryInterceptor" /> </bind>

<bind

pointcut="call(* $instanceofjavax.servlet.http.HttpServletResponse ‐> sendRedirect*(java.lang.String))">

<interceptor class="aprosec.RedirectInterceptor" /> </bind>

</aop>

Cada etiqueta <bind> indica un punto de corte en el que se realizará una intercepción y la definición de una clase que deberá tomar el control. Cada una de las clases en el archivo debe implementar el método invoke() de la interfaz org.jboss.aop.Interceptor. En este caso, cada clase

80

únicamente reenvía la llamada a las funciones de AProSec, para poder reutilizar el código del aspecto en cualquier implementación que se haga.

8.5 RESULTADOS DE APLICAR APROSEC

Al utilizar AProSec para proteger la aplicación vulnerable que se muestra en el capítulo 7, en cuestión de segundos la aplicación queda segura contra todos los ataques mostrados en la sección 7.3. El ataque a la página de autenticación no funciona, mostrando una pantalla de error en la autenticación, como se muestra en la figura 8.3.

Fig. 8.3 Prevención de ataque con comilla en la autenticación

El ataque no funciona debido a que AProSec realiza la sustitución de comillas y la consulta queda de la siguiente manera:

select id_user, user_name, email, login, pw, admin from userinfo where login = '\' or 1=1#' and pw = ''

Incluso cuando se intenta realizar un ataque con diagonal invertida, el ataque no es permitido, como se ve en la figura 8.4.

Fig. 8.4 Prevención de ataque con diagonal invertida en la autenticación

81

En este caso, AProSec también realiza la sustitución de la diagonal invertida para evitar que sirva como carácter de escape y penetre el ataque, quedando la petición como sigue:

select id_user, user_name, email, login, pw, admin from userinfo where login = '\\\' or 1=1#' and pw = ''

De manera que todo el contenido de la forma en el campo Login queda como texto dentro de la petición a la base de datos y no hay inyección de código SQL.

Lo mismo sucede cuando se intenta realizar el ataque al campo de búsqueda, dando como resultado una búsqueda vacía, tal como lo muestra la figura 8.5. El principio es el mismo que en los dos ejemplos anteriores, cuando AProSec elimina la inyección de SQL.

Fig. 8.5 Prevención de ataque con UNION en la búsqueda

Al hacer esta petición, la consulta incluye todo el texto dentro del campo de búsqueda, dejando la petición así:

SELECT id_product, product_name, description, price, image, active

FROM product WHERE active = 1

AND (

product_name LIKE '%x\') union select 9, login, pw, 4, 5, 6 from userinfo#%' or description LIKE '%x%'

)

AProSec también evita los ataques de XSS eliminando los contenidos peligrosos de los comentarios. En la figura 8.6 se muestra la inserción de un comentario con contenido peligroso y en la figura 8.7 el resultado después de ser validado por AProSec.

82

Fig. 8.6 Ataque de XSS al agregar un comentar io

Fig. 8.7 Resultado de la inserción con la validación de AProSec

Como se puede observar, la inserción del código se toma como texto y el código nunca es ejecutado, simplemente se muestra como parte del comentario. Si se revisa el código fuente que genera esta entrada, podemos ver realmente lo que se almacenó en la base de datos:

Mi comentario &lt;script&gt;alert("Vulnerable a XSS");&lt;/script&gt;

Por lo que el ataque de XSS no llega a afectar a ningún usuario. De igual forma, cuando un usuario ingresa una etiqueta válida (en este ejemplo las etiquetas <a> u <br> se consideran válidas), AProSec realizará las validaciones en el cuerpo de la etiqueta. En la figura 8.8 se muestra la inserción de un comentario con etiquetas válidas:

Fig. 8.8 Insertar un comentario con etiquetas válidas

83

Esta inserción, después de ser validada por AProSec generaría la salida que se muestra en la figura 8.9. Al ser ambas etiquetas válidas, se respetan las ligas y los saltos de línea.

Fig. 8.9 Resultado de un comentario con etiquetas válidas con AProSec

Se puede observar que ambas ligas están activas. La primer liga nos manda a http://google.com, mientras que la segunda no hace nada. Si revisamos el código fuente nos daremos cuenta de la razón. Al validar las etiquetas con AProSec, el cuerpo del comentario en HTML queda como sigue:

Una liga normal <a href="http://google.com">aquí</a>.<br> Una liga maliciosa <a href="#" >acá</a>.

Se puede ver que la llamada al código de JavaScript que se encontraba en el atributo onClick fue eliminada del comentario y lo único que queda es la liga que no apunta a ningún lado. Con esto se evita que un usuario malintencionado inserte código que puede resultar perjudicial para el resto de los usuarios.

Finalmente, cuando se intenta generar una inyección de encabezados en una redirección, AProSec limpia las entradas de CR y LF que encuentre, dejando libre de saltos de línea a la dirección. Cuando se inserta una dirección como la mostrada en la sección 7.3.3:

http://localhost:8888/virtuaStore/?act=goto&url=%0D%0AContent‐ Type:%20text/html%0D%0A%0D%0A%3Cdiv%20id= 'x'%3E

%3Cdiv%20id='y'%3E%3Cscript%20src='file.js'%3E%3C/script%3Ehttp://www.algo.com

Esta sería transformada por AProSec dejándola sin saltos de línea y como una sola petición:

http://localhost:8888/virtuaStore/?act=goto&url=Content‐ Type:text/html%3Cdiv%20id='x'%3E%3Cdiv%20id='y'%3E%3Cscript%20src='file.js'%3E%

3C/script%3Ehttp://www.test.com

Esta dirección, dependiendo del servidor de aplicaciones y del navegador utilizado generaría una pantalla en blanco o un mensaje de error 404 (página no encontrada).

84

9 PROYECTOS RELACIONADOS

La seguridad en las aplicaciones no es un tema nuevo y ha llamado la atención de los investigadores desde hace mucho tiempo, por esta razón existen ya varios trabajos que intentan abordar los problemas que se manejan en este proyecto, principalmente la inyección de código SQL y los ataques de XSS. La manera en que plantean la solución de estos problemas involucra en casi todos los casos un trabajo directo con el código de la aplicación o con la base de datos, lo que hace que las propuestas sean difíciles de implementar y en algunos casos, incluso de comprender.

9.1 TRABAJOS RELACIONADOS CON LOS ATAQUES DE INYECCIÓN DE SQL Y XSS

La mejor manera para proteger una aplicación contra ataques de inyección de SQL es revisar toda la información que los usuarios introducen a la aplicación. La mayoría de los trabajos en esta área intentan limitar la manera en que una petición de base de datos es utilizada, permitiendo únicamente las peticiones que el programador desea permitir.

En uno de los proyectos, los autores proponen el uso de un árbol con la estructura de la petición de SQL [24]. Para lograr esto, la gramática del lenguaje SQL debe ser conocida. Se debe resaltar que la gramática de SQL llega a cambiar entre diferentes servidores de base de datos. Esta técnica produce un árbol con el análisis de la petición original y lo compara con un nuevo árbol que se genera al incluir la información del usuario. Si los dos árboles son iguales se procede con la ejecución, pero si son diferentes, es decir, le agregaron o excluyeron comandos y por lo tanto se generó un árbol distinto, entonces se detecta la inyección. Si en la aplicación se cambia alguna petición, se deben volver a generar los árboles para tener la base con la cual se va a comparar.

El proyecto AMNESIA propone un modelo en el cual se pueden detectar y prevenir ataques de inyección de SQL combinando un análisis previo y un monitoreo durante la ejecución de la aplicación [25]. En la primera fase, se hace un análisis del código fuente para generar un modelo que guarde las consultas válidas. En la segunda fase, utilizando un monitoreo activo, se compara cada petición a la base de datos con el modelo generado previamente para identificar posibles

85

inyecciones y prevenir que se ejecuten las peticiones que no coincidan. El éxito de este proyecto depende completamente del modelo generado durante la primera fase, el cual puede degradado cuando se utilizan herramientas de ofuscación de código o algunas técnicas de generación de peticiones [26].

Otro proyecto utilizando evaluación de cadenas de texto sensibles al contexto, propone una solución que no requiere de modificar el código fuente de la aplicación [27]. Sirve para aplicaciones que utilizan PHP y para funcionar requiere modificar el entorno de ejecución de PHP para detectar los ataques de inyección en todas las aplicaciones que están corriendo sobre el mismo ambiente. La desventaja de este proyecto es que al ser dependiente del ambiente de ejecución, la portabilidad se ve afectada [26]. El mismo autor reconoce que se debe hacer una implementación diferente para cada plataforma en la que se vaya a correr.

La ventaja de AProSec sobre estos proyectos es que está basado en programación orientada a aspectos y que considera además los tres ataques en el mismo aspecto: Inyección de SQL, XSS y división de respuesta de HTTP. También tiene la ventaja de que puede ser agregado en tiempo de ejecución, sin necesidad de volver a compilar la aplicación para incorporarlo. Además, cualquier cambio que se haga en el archivo de configuración se toma de inmediato, sin necesidad de detener o reiniciar el servidor de aplicaciones.

9.2 TRABAJOS SOBRE SEGURIDAD CON PROGRAMACIÓN ORIENTADA A ASPECTOS

Existen varios trabajos sobre seguridad utilizando programación orientada a aspectos, pero la gran mayoría se enfoca a proyectos de control de acceso, registro de bitácoras, firmas digitales, autenticación y autenticación.

En un proyecto se propone un perfil de orientación a aspectos de UML para identificar escenarios de ataques [28]. En el modelo se utilizan diagramas de clases y diagramas de máquinas de estados para representar los posibles comportamientos de un atacante y los procesos para detectarlo. Consiste en cinco etapas: identificar vulnerabilidades y ataques, modelar los escenarios de los ataques utilizando UML, generar el aspecto de detección de intrusiones utilizando un generador de código de aspectos, integrar el aspecto a la aplicación y probar y ejecutar la aplicación integrada.

Un proyecto muy similar al que se plantea en este trabajo es el propuesto por Kawachi y Masuhara [29]. En este proyecto se propone un aspecto para la detección de ataques de XSS, para lo que limpian las entradas de los usuarios sustituyendo algunos caracteres especiales por caracteres escapados o su equivalente en HTML. Proponen dos escenarios, uno en donde la información viene de un usuario y por lo tanto debe ser validada y otro en donde la información viene de otro servlet de la misma aplicación, en cuyo caso se toma como una fuente confiable y

86

se evita la validación para ahorrar tiempo de procesamiento. Para el primer escenario se propone una extensión a la sintaxis de AspectJ en la cual se pueda especificar el origen de la información en un constructor especial. Esta última parte se plantea solamente como idea y no fue implementada.

87

10 RESULTADOS Y CONCLUSIONES

La programación orientada a aspectos vino a cambiar la forma en que se pueden abordar algunos conceptos, como la seguridad, planteando soluciones sencillas para muchos problemas. Entre sus mayores ventajas está el que no se requiere modificar una aplicación existente para poder aprovechar sus bondades, por lo que puede irse adoptando poco a poco en ambientes de producción sin mucho trabajo por atrás y con grandes ganancias.

Al utilizar la programación orientada a aspectos como un medio para mejorar la seguridad en las aplicaciones, se pueden lograr grandes avances simplemente con agregar los aspectos necesarios. En el caso de AProSec, se puede proteger, en cuestión de segundos, una aplicación contra las tres principales vulnerabilidades que tiene las aplicaciones por falta de validación en la información proveída por los usuarios: Inyección de código SQL, ataques de XSS y división de respuesta de HTTP.

AProSec tiene la gran ventaja de que puede ser parametrizado para cada aplicación por medio de un archivo de configuración en donde se especifican cada una de las posibles validaciones a realizar. Los cambios en el archivo de configuración se toman de manera inmediata, lo que facilita el mantenimiento y pruebas en las aplicaciones. Entre las opciones está el registro de eventos, lo que permite que un administrador analice las salidas y vea si están intentando atacar la aplicación o valorar si algunas etiquetas deberían ser agregadas como permitidas.

El aspecto puede evolucionar de manera independiente, pues no está ligado al código de ninguna aplicación. Se pueden añadir más módulos y validaciones o hacer los cambios necesarios en el código ya existente y reflejar estos cambios las aplicaciones sin necesidad de modificarlas. Con la incorporación en tiempo de ejecución, ni siquiera es necesario volver a compilar las aplicaciones para que puedan utilizar las nuevas versiones del aspecto.

El incrustar código con validaciones a las aplicaciones tiene como consecuencia lógica un procesamiento adicional que ocasiona una respuesta más lenta, pero después de generar un análisis estadístico, se obtuvo que al integrar AProSec en una aplicación, con todas las validaciones activadas, la diferencia en los tiempos de respuesta es en promedio de únicamente 0.0035 segundos. Este tiempo es bastante pequeño, sobre todo si se consideran todas las ventajas que ofrece la protección con el aspecto.

88

Este proyecto de investigación fue parcialmente financiado por el laboratorio Franco­Mexicano de Informática y fue realizado con el apoyo del equipo ADAM 27 del INRIA 28 en Lille, Francia. El trabajo fue presentado en el congreso internacional ARES 2007, en Viena, Austria, con el artículo “AProSec: an Aspect for Programming Secure Web Applications” [30]. Más adelante se nos pidió una colaboración sobre el mismo tema para la revista The Journal of Software en diciembre de 2007, para la cual se realizó el artículo titulado “Using Aspect Programming to Secure Web Applications” [31].

27 Adaptive Distributed Applications and Middleware. 28 Institut National de Recherche en Informatique et en Automatique. (Instituto Nacional de Investigación en Informática y Automática).

89

REFERENCIAS

[1] DE WIN, Bart, VANHAUTE, Bart y DE DECKER, Bart. Security through Aspect­Oriented Programming. Proceedings of the IFIP TC11 WG11.4 First Annual Working Conference on Network Security. p. 125­138. Kluwer, B.V.: 2001. ISBN: 0792375580.

[2] VIEGA, John, BLOCH, J.T. y CHANDRA, Pravir. Applying Aspect­Oriented Programming to Security. Cutter IT Journal. Febrero de 2001 [fecha de consulta: enero de 2008]. Disponible en: http://www.ccs.neu.edu/home/lieber/courses/csg379/f04/resources/aop­cutter.pdf.

[3] OWASP Top Ten Most Critical Web Application Security Vulnerabilities [fecha de consulta: noviembre de 2007]. Disponible en: http://www.owasp.org.

[4] VIEGA, John y MCGRAW, Gary. Building Secure Software: How to Avoid Security Problems the Right Way. Boston, MA: Addison­Wesley, 2001. ISBN: 020172152X.

[5] KICZALES, Gregor, LAMPING, John, MENHDHEKAR, Anurag, MAEDA, Chris, LOPES, Cristina, LOINGTIER, Jean­Marc y IRWIN, John. Aspect­Oriented Programming. Proceedings of the 11th European Conference on Object­Oriented Programming (ECOOP'97). Vol. 1241. p. 220­242, junio 1997. Springer­Verlag.

[6] KICZALES, Gregor, HILSDALE, Erik, HUGUNIN, Jim, KERSTEN, Mik, PALM, Jeffrey y GRISWOLD, William G.. An Overview of AspectJ. Proceedings of the 15 th European Conference on Object­Oriented Programming (ECOOP'01). Vol. 2072. p. 327­353, junio 2001. Springer­Verlag.

[7] FLEURY, Marc y REVERBEL, Francisco. The JBoss Extensible Server. Proceedings of the 4th ACM/IFIP/USENIX International Conference on Distributed Systems Platforms and Open Distributed Processing (Middleware'03). Vol. 2672. p. 344­373, junio 2003. Springer­ Verlag.

[8] Web Application Security Statistics ­ Web Application Security Consortium [fecha de consulta: noviembre de 2007]. Disponible en: http://www.webappsec.org.

[9] Common Vulnerabilities and Exposures (CVE) [fecha de consulta: noviembre de 2007]. Disponible en: http://www.cve.mitre.org.

90

[10] ROSS, David, BRUGIOLO, Ivan, COATES, John y ROE, Michael. Cross­site Scripting Overview. Febrero 2000 [fecha de consulta: enero de 2008]. Disponible en: http://ha.ckers.org/cross­site­scripting.html.

[11] GROSSMAN, Jeremiah, HANSEN, Robert, PETKOV, Petko, RAGER, Anton y FOGIE, Seth. XSS Attacks. Bulrington, MA: Syngress, 2007. ISBN: 9781597491549.

[12] KAMKAR, Samy. Technical explanation of the MySpace worm [fecha de consulta: enero de 2008]. Disponible en: http://namb.la/popular/tech.html.

[13] YOUNG, Susan y AITEL, Dave. The Hacker's Handbook. Boca Raton, FL: Auerbach Pub, 2003. ISBN: 0849308887.

[14] RFC 2616 ­ Hypertext Transfer Protocol ­­ HTTP/1.1. [fecha de consulta: enero de 2008] Disponible en: http://www.ietf.org/rfc/rfc2616.txt.

[15] KLEIN, Amit. Divide and Conquer. HTTP Response splitting, Web Cache Poisoning Attacks, and Related Topics [fecha de consulta: enero de 2008]. Disponible en: http://www.watchfire.com/securityzone/whitepapers.aspx.

[16] LIEBERHERR, Karl J. Adaptive Object­Oriented Software: The Demeter Method with Propagation Patterns. PWS Publishing Company, Boston. 1996 [fecha de consulta: febrero de 2008]. Disponible en: http://www.ccs.neu.edu/research/demeter/book/aoos.PDF. ISBN: 053494602X.

[17] FILMAN, Robert E., ELRAD, Tzilla, CLARKE, Siobhan y AKŞIT, Mehmet. Aspect­ Oriented Software Development. Boston, MA: Addison­Wesley, 2004. ISBN: 0321219767.

[18] REINA, Antonia María. Visión General de la Programación Orientada a Aspectos. Artítulo técnico, LSI­2000­11 del Dpto. Lenguajes y Sistemas Informáticos. Universidad de Sevilla. Sevilla, España. Diciembre, 2000 [fecha de consulta: febrero de 2008]. Disponible en http://www.lsi.us.es/~informes/aopv3.pdf.

[19] PAWLAK, Renaud, RETAILLÉ, Jean­Philippe y SEINTURIER, Lionel. Programmation orientée aspect pour Java / J2EE. Paris: Groupe Eyrolles, 2004. ISBN: 2212114087.

[20] HILSDALE, Erik, KICZALES, Gregor, GRISWOLD, Bill, HUGUNIN, Jim, ISBERG, Wes y KERSTEN, Mik. Aspect­Oriented Programming with AspectJ™. Diapositivas del tutorial en línea. 2003 [fecha de consulta: enero de 2008]. Disponible en: http://www.ccs.neu.edu/research/demeter/course/w03/lectures/lecAspectJ­w03.ppt

[21] CRAWFORD, William y KAPLAN, Jonathan. J2EE design patterns. Beijing; Farnham: O'Reilly Media, Inc., 2003. ISBN: 0596004273.

[22] LADDAD, Ramnivas. AspectJ in Action. Greenwich, CT. Manning Publications Co.: 2003. ISBN: 1930110936.

91

[23] PAWLAK, Renaud, RETAILLÉ, Jean­Philippe y SEINTURIER, Lionel. Foundations of AOP for J2EE Development. Berkeley, CA: Apress Academic, 2005. ISBN: 1590595076.

[24] BUEHRER, Gregory, WEIDEM, Bruce W. y SIVILOTTI, Paolo A. G. Using Parse Tree Validation to Prevent SQL Injection Attacks. Proceedings of the 5th international workshop on Software engineering and middleware. p. 106­113. Lisbon, Portugal: ACM, 2005.

[25] HALFOND, William G. J. y ORSO, Alessandro. AMNESIA: analysis and monitoring for NEutralizing SQL­injection attacks. Proceedings of the 20th IEEE/ACM international Conference on Automated software engineering. p. 174­183. Long Beach, CA, EE.UU.: ACM, 2005.

[26] HALFOND, William G.J., VIEGAS, Jeremy y ORSO, Alessandro. A Classification of SQL­Injection Attacks and Countermeasures. Proceedings of the IEEE International Symposium on Secure Software Engineering (ISSSE 2006). Arlington, VA, USA: 2006.

[27] PIETRASZEK, Tadeusz y BERGHE, Chris Vanden. Defending against Injection Attacks through Context­Sensitive String Evaluation. Recent Advances in Intrusion Detection 2005 (RAID). 2005.

[28] ZHI JIAN, Zhu y ZULKERNINE, Mohammad. Towards an Aspect­Oriented Intrusion Detection Framework. Computer Software and Applications Conference, 2007 (COMPSAC 2007). Beijing, China: 2007. ISBN: 0769528708.

[29] KAWAUCHI, Kazunori y MASUHARA, Hidehiko. Dataflow Pointcut for Integrity Concerns. In Proceedings of AOSD 2004 Workshop on AOSD Technology for Application­ level Security (AOSDSEC). Lancaster, UK: 2004.

[30] HERMOSILLO, Gabriel, GOMEZ, Roberto, SEINTURIER, Lionel y DUCHIEN, Laurence. AProSec: an Aspect for Programming Secure Web Applications. The Second International Conference on Availability, Reliability and Security (ARES 2007). p. 1026­ 1033. Vienna, Austria: 2007.

[31] HERMOSILLO, Gabriel, GOMEZ, Roberto, SEINTURIER, Lionel y DUCHIEN, Laurence. Using Aspect Programming to Secure Web Applications. Journal of Software. Vol. 2 (6). p. 53­63. Diciembre 2007 [fecha de consulta: enero de 2008]. Disponible en: http://www.academypublisher.com/jsw/vol02/no06/jsw02065363.pdf. ISSN: 1796217X.