23-setiembre Cristian Cappo Facultad Politécnica, UNA

Transcripción

1 23-setiembre-2009 Cristian Cappo Facultad Politécnica, UNA En el marco de la VIII Exposición Tecnológica y Científica 2009

2 Cristian Cappo: Graduado de la Facultad Politécnica de la Universidad Nacional de Asunción (FPUNA) en Análisis de Sistemas Informáticos. Profesor de la FPUNA (desde el año 1999): Algoritmos y Estructura de Datos (Ing. Informática) Algoritmos (fundamentos de programación) (Ing. en Electrónica) Estructura de los lenguajes (Lic. en Ciencias Informáticas) Actualmente docente e investigador a tiempo completo de la Universidad Nacional de Asunción (DITCoDE ) y alumno de doctorado del Programa de Posgrado en Informática de la FPUNA (desde julio/2009)

3 1. Aplicaciones y arquitectura web 2. Problemas, vulnerabilidades y ataques 3. Lidiando con las vulnerabilidades 3.1 Análisis estático 3.2 Detección de intrusión. Generalidades 3.3 Detección de intrusión en aplicaciones web 4. Investigación en el área - FPUNA

4 Success is foreseeing failure El éxito es prever el fracaso Henry Petrosky Colapso del puente Tacoma Narrow (USA-1940)

5

6 Son aplicaciones que utilizan la infraestructura web para su funcionamiento, por ejemplo Internet. La web se ha convertido en el medio natural para desplegar los servicios de software Existen actualmente cerca de 30 mil millones de sitios web indexados (agosto/2009) por Google, Msn, Yahoo y Ask ( Es raro que un sitio web NO tenga al menos una aplicación que tenga capacidad de generar contenido dinámico y de recibir datos de sus potenciales usuarios.

7 Las aplicaciones para web son fáciles de construir, desarrollar y desplegar.

8 Ventajas Basado en un protocolo simple como HTTP (ligero y sin estado) Solo se requiere de un navegador (browser) Los navegadores ofrecen todo lo necesario para construir interfaces atractivas a los usuarios. Además es posible hacer parte (a veces bastante) del procesamiento del lado cliente. La tecnología y los entornos de desarrollo de las aplicaciones se están volviendo relativamente simples. Existen numerosas herramientas de acceso gratuito y otros recursos para incorporar a las aplicaciones propias.

9 Esquema básico/usual del entorno web Firewall Cliente Web Servidor Web App - Web App - Web Servidor de Base de datos Tráfico HTTP Puerto 80

10 Todas las transacciones HTTP siguen el mismo formato. Cada solicitud del cliente (request) y la respuesta del servidor (response) tienen tres partes: la línea request o response, una cabecera (header) y un cuerpo (body).

11 Métodos HTTP básicos Método Descripción Body? GET Solicitar un documento del servidor No HEAD Solicitar solo el header del servidor No POST Enviar datos al servidor para su procesamiento Si PUT Guardar el cuerpo del request en el servidor Si TRACE OPTIONS Mostrar la traza del mensaje a través de los proxys al server Determina que métodos están habilitados en el servidor DELETE Borra un documento del servidor No No No

12

13

14 HTTP no fue diseñado para aplicaciones El desarrollo de aplicaciones web es desordenado. Las aplicaciones web de por sí, no son seguras. La seguridad en esta área aún es joven. Generalmente los servidores web no proveen buenas herramientas de monitoreo. Existe una conciencia que esta aumentando pero hay un largo camino a recorrer.

15 Así como hay un aumento de número de aplicaciones también crecen los problemas de seguridad debido fundamentalmente a: Conocimientos insuficientes sobre seguridad Tiempo de desarrollo e implementación muy ajustados. Por tanto Aumento en número y severidad de los huecos de seguridad en las aplicaciones: AUMENTO DE VULNERABILIDADES.

16 Hacer lo correcto desde el principio es lo mejor Los desarrolladores deben diseñar y construir software seguro.!la seguridad es ahora parte de la programación! Pero No es posible 100% de seguridad. Se usa productos de terceros del que no se conoce su calidad y en particular su seguridad. Debemos convivir con sistemas que ya están funcionando (sistemas heredados)

17 Si es posible mejorar el software, debe hacerse! Pero es probable que se tenga que aumentar la seguridad desde el exterior y no es fácil. Se debe colocar aplicaciones inseguras en entornos seguros Debe usarse un modelo de amenazas en la implementación para determinar los huecos. Las deficiencias de arquitectura deben ser corregidas. Se debe limitar la exposición a través de un correcto diseño de red.

18 Aspectos a tener sobre seguridad: Monitoreo: Conocer que esta ocurriendo Buenas herramientas del sistema operativo Detección: Conocer cuando existe un ataque Intrusion Detection Systems Prevención: Detener el ataque antes que logre su objetivo Intrusion Prevention Systems Evaluación: Descubrir los problemas antes que los atacantes Análisis estático

19 Principios básicos de seguridad en las aplicaciones web No confiar en la entrada del usuario Revisar huecos de lógica Brindar solo la información necesaria Construir y probar para soportar la carga Carga potencial esperada Ataques de DoS (Denegación de servicio)

20 Firewall DataBase DataBase Cliente Web Servidor Web App - Web App - Web DataBase Tráfico HTTP GET /login.pl?user= Puerto 80 El firewall no puede contrarrestar ataques que vienen en el contenido de los paquetes HTTP (que es puerto abierto)

21 Descubrimiento Examinar el entorno (nmap por ejemplo) Identificar puertos abiertos (port scan) Descubrimiento de tipo y versiones de las aplicaciones Generar y examinar errores Mediante entradas ridículas que provoquen errores Son útiles los errores de base de datos y los trazos de ejecución (stack trace). Encontrar información detrás (código fuente, comentarios, campos ocultos, etc). Definición del objetivo (target) Mecanismo de login Campos de entrada Manejo de sesiones (cookies) Infraestructura Y más

22 Qué es una vulnerabilidad? Es una debilidad o hueco de seguridad que posee una aplicación la que puede ser aprovechada o explotada de forma malintencionada por un atacante y violar así la seguridad del sistema.

23 Open Web Application Security Project (Proyecto Abierto de Seguridad en Aplicaciones Web) Organización que se dedica a ayudar a entender y mejorar la seguridad en las aplicaciones y servicios web. OWASP Guide to Building Secure Web Applications, Lista las diez vulnerabilidades más importantes dadas en aplicaciones web. El último reporte es del OWASP Top Tiene relación con CVE (Common Vulnerability and Exposures ( cve.mitre.org ) ) : identificación, codificación y registro de vulnerabilidades. Cerca de 50% de las vulnerabilidades registradas corresponden a aplicaciones web.

24

25 1. Secuencia de Comandos en Sitios Cruzados (XSS). 2. Fallas de inyección 3. Ejecución de ficheros malintencionados 4. Referencia insegura y Directa a objetos 5. Falsificación de Petición de Sitios Cruzados (CSRF) 6. Revelación de información y gestión incorrecta de errores. 7. Pérdida de autenticación y gestión de sesiones. 8. Almacenamiento criptográfico inseguro. 9. Comunicaciones inseguras 10. Falla de restricción de acceso a URL.

26 1) Secuencia de Comandos en Sitios Cruzados (XSS) La aplicación puede ser usada como un mecanismo para transportar un ataque al usuario final con un navegador. El navegador del usuario no tiene forma de conocer que el script es no validado o malicioso, y lo ejecuta. Puede acceder a cookies, tokens de sesión o información sensible guardada en el navegador. Eventualmente pueden reescribir totalmente el contenido de la página HTML.

27 Pueden ser categorizados en dos clases Permanentes: Se guardan en el servidor, como por ejemplo una base de datos, en un foro, en un blog, comentario, etc. Requiere que la víctima acceda al sitio web contaminado. Reflejados El código inyectado es reflejado fuera del servidor, tal como un mensaje de error, resultado de búsqueda, o cualquier otra respuesta que incluya alguno o todas las entradas enviadas al servidor como parte de la petición.

28 Consideremos de siguiente script Perl $query = new CGI; Entrada no validada $directory = $query->param( msg ); print <html><body> <form action= displaytext.pl method= get > $msg <br> <input type= text name= txt > <input type= submit value= OK > </form></body></html> ; Si se le invoca text.pl?msg=hola Mundo entonces vemos lo siguiente:

29 El código anterior es vulnerable a XSS. La entrada no es validada por tanto puede inyectarse código en la página Si introducimos en el URL text.pl?msg=<script>alert( Hola )</script> <html><body> <form action="displaytext.pl" method="get"> <script> alert("hola") </script> <br> <input type="text" name="txt"> <input type="submit" value="ok"> </form></body></html>

30 Usuario hace login El usuario solicita el URL malicioso al servidor El server responde con el script del atacante El atacante secuestra la sesión del usuario El script del atacante Se ejecuta en el navegador Del usuario 5 El atacante envía un URL malicioso al usuario 2 6 El navegador del usuario envía el dato al atacante

31 Usuario hace login El usuario ve la respuesta del atacante El server responde con el script del atacante El atacante envía una respuesta conteniendo un script malicioso El atacante secuestra la sesión del usuario El script del atacante Se ejecuta en el navegador Del usuario 5 6 El navegador del usuario envía el dato al atacante

32 2) Fallas de inyección La inyección ocurre cuando los datos proporcionados por el usuario son enviados e interpretados como parte de una orden o consulta. Existen varios tipos: SQL, LDAP, XPath, XSLT, XML, ordenes de sistemas operativos entre otros. El más común es la inyección de sentencias o comandos SQL.

33 Permite a los atacantes retransmitir código a través de la aplicación web a otro sistema vía SQL. Para aprovechar una vulnerabilidad de este estilo el atacante debe encontrar un parámetro que la aplicación utiliza para construir una consulta SQL. Las consecuencias son varias: Obtener información privada Corromper o destruir el contenido de un base de datos Ejecutar comandos del sistema operativo Y otros..

34 Consideremos el siguiente código perl $query = new CGI; $username = $query->param( username ); $password = $query->param( password ); $sql_command = select * from users where username= $username and password= $password ; $sth = $dbh->prepare($sql_command) No validado

35 Un atacante podría aprovechar esta vulnerabilidad: Agregar or 1=1 en el campo password, de forma que la consulta queda select * from users where username= juan and password= or 1=1 De esta forma el atacante logro acceder a la aplicación.

36 Otros ejemplos de código vulnerable: En PHP $sql = "SELECT * FROM table WHERE id = '". $_REQUEST['id ]. " "; En Java String query = "SELECT user_id FROM user_data WHERE user_name = '" + req.getparameter("userid") + "' and user_password = '" + req.getparameter("pwd") +"'";

37 Otras palabras claves a detectar Exec XP_ Exec SP_ OpenRowSet Execute inmediate UNION SELECT INSERT DELETE UPDATE

38 3) Ejecución de ficheros malintencionados En muchas plataformas, el entorno de trabajo permite el uso de referencias a objetos externos, como URLs o referencias al sistema de ficheros. Cuando los datos no son comprobados correctamente, esto puede llevar a que se incluya, procese o ejecute contenido arbitrario hostil y remoto por el servidor Web.

39 Permite a un atacante Ejecución remota de código Instalación remota de rootkits y así controlar el sistema completo. Comúnmente se da en sistemas que usan PHP (inclusión remota de archivos). El daño causado es proporcional a la fortaleza del aislamiento de la plataforma del entorno de trabajo. El siguiente fragmento de código PHP es vulnerable a inclusión remota: include $_REQUEST['filename ]; programa.php?filename=

40 4) Referencia insegura y Directa a objetos Ocurre cuando un programador expone una referencia hacia un objeto interno de la aplicación tales como un archivo, directorio, registro de la base de datos, o clave como un URL o un parámetro de formulario web

41 Ejemplo 1: <select name="language"> <option value="fr">français</option></select> require_once($_request['language ]."lang.php"); Este código puede ser atacado suministrando una cadena como../../../../etc/passwd%00 y acceder a archivos del sistema (fijarse que se inyectó el byte nulo %00 y así evitar que se añada otra cadena, lang.php en este caso)

42 Ejemplo 2: Un atacante puede explotar la vulnerabilidad probando con varios valores para una clave que está expuesta por la aplicación. int cartid = Integer.parseInt( request.getparameter("cartid" )); String query = "SELECT * FROM table WHERE cartid=" + cartid;

43 5) Falsificación de Petición de Sitios Cruzados (CSRF) Un ataque CSRF fuerza el navegador validado de una víctima a enviar una petición a una aplicación Web vulnerable, la que realiza la acción elegida a través de la víctima.

44 El usuario solicita al servidor la petición El server responde Usuario hace login a una aplicación El atacante utiliza el dato de la sesión del usuario para personalizarse 2 5 El usuario visita una página del atacante que tiene un CSFR El navegador del usuario envía el dato de la sesión al atacante

45 El servidor responde e incluye un cookie

46 El atacante ha inyectado un iframe

47 6) Revelación de información y gestión incorrecta de errores. Las aplicaciones pueden revelar, involuntariamente, información sobre su configuración, su funcionamiento interno, o pueden violar la privacidad a través de una variedad de problemas. Las aplicaciones Web suelen revelar información sobre su estado interno a través de mensajes de error detallados o de depuración. Esta información, a menudo, puede ser utilizada para lanzar, o incluso automatizar, ataques muy potentes.

48

49 7) Pérdida de autenticación y gestión de sesiones. Implican fallas en la protección de credenciales y tokens de sesión a través de su ciclo de vida. Se presentan habitualmente en las funciones auxiliares de autenticación como el cierre de sesión, gestión de contraseñas, expiración de sesión, recuérdame, pregunta secreta y actualización de la cuenta.

50 8) Almacenamiento criptográfico inseguro Se refiere a la falta de cifrar datos que son delicados ó aplicar algoritmos de criptografía mal diseñados. Ejemplo en PHP... $props = file('config.properties', FILE_IGNORE_NEW_LINES FILE_SKIP_EMPTY_LINES); $password = base64_decode($props[0]); $link = mysql_connect($url, $usr, $password); if (!$link) { die('could not connect: '. mysql_error()); }..

51 9) Comunicaciones inseguras Falta de uso de canales seguros como SSL que aseguren el cifrado de la comunicación y evitar que los atacantes puedan husmear en el tráfico de red.

52 10) Falla de restricción de acceso a URL. Se refiere a la protección que se debe dar a URLs que son delicadas. Normalmente solo se usa solo una restricción de visualización (seguridad por oscuridad) pero no es suficiente. Algunos ejemplos: URL ocultas o especiales suministradas solo a administradores. Archivos especiales ocultos. Código que evalúa privilegios en el cliente y no en el servidor.

53 Otras (en la versión OWASP 2004) - Desbordamiento de buffers (buffer overflow) - Su objetivo es corromper la pila de ejecución de una aplicación web y así poder ejecutar código malicioso. Normalmente aplicable a CGI y no a lenguajes interpretados (PHP, Perl, Java, JSP, etc). - Denegación de servicio (DoS) - Consumo de los recursos de tal forma que los usuarios lícitos no pueden acceder a los servicios. - Manejo inseguro de configuración - Configuración por defecto: usuarios, archivos, configuraciones, funciones.

54

55 En la etapa de desarrollo (estático) Utilizando analizadores estáticos de código En la etapa de producción (dinámico) Utilizando los detectores de intrusión

56

57 Permiten detectar vulnerabilidades en el proceso de construcción de la aplicación. Deben estar apoyados por una metodología que incluya revisiones de seguridad en cada etapa de construcción de la aplicación.

58 Existen herramientas que permiten encontrar vulnerabilidades (algunos ejemplos) LAPSE: Lightweight Analysis for Program Security in Eclipse (para Java) findbugs (para Java) Fortify Inc: Bibliografía: Secure Programming with static analysis. Brian Chess and Jacob West

59 Fortify Sw Inc. posee una página interesante donde puede encontrarse una lista de errores de programación y diseño en varios lenguajes de programación (

60

61 El número de incidentes de seguridad sigue creciendo, los administradores de redes y sistemas aplican de forma lenta las medidas correctivas. El desarrollo de mecanismos de seguridad como la autenticación y el control de acceso pueden ser deshabilitados como consecuencia de una mala configuración o de acciones maliciosas. Los usuarios de un sistema pueden abusar de sus privilegios y realizar acciones dañinas. Aún cuando un ataque no tuvo éxito es importante enterarse del intento.

62 Un sistema de detección de intrusión (IDS) es un software que detecta accesos sin autorización a una red de datos o un sistema computacional. Es capaz de detectar el tráfico malicioso en una red o el uso anormal de las computadoras. Un IDS es un entidad dinámica de monitoreo que complementa las habilidades de un firewall.

63 Organización de un IDS generalizado [Axelsson, 1998] Flujo de datos/control Respuesta a actividad intrusiva

64 Audit collection Recolectar los datos sobre la entidad monitoreada. Audit data storage: Módulo para guardar los datos que serán analizados. Analysis and detection Implementa los algoritmos de detección Configuration data Contiene información de configuración del detector. Por ejemplo: niveles de sensibilidad, tiempo de recolección, respuesta a las intrusiones, etc. Reference data Datos sobre ataques conocidos (signature) o perfil de funcionamiento del sistema (anomaly). Active/Processing data Datos de resultados parciales Alarm Es la parte que maneja la salida del IDS. Puede ser una respuesta automática a una intrusión o la emisión de una alerta al administrador de seguridad de la organización.

65 Firewall Servidor Web App - Web App - Web Servidor de Base de datos IDS Cliente Web Servidor Web App - Web App - Web Servidor de Base de datos Tráfico HTTP Puerto 80

66 Un IDS debe llenar los siguientes requerimientos [Dacier et al, 1999] Precisión No debe identificar una acción legítima como intrusiva (Una acción legítima identificada como falsa es llamada Falso- Positivo) Rendimiento Con posibilidad de reaccionar en tiempo real antes de que una intrusión tenga éxito. Completitud No debe fallar en detectar una intrusión (una intrusión no detectada es llamada falso-negativo). Tolerancia a fallas Un IDS debe ser resistente a ataques Escalabilidad: Un IDS debe ser capaz de procesar el número de eventos correspondiente al peor caso sin perder información.

67 Según su arquitectura NIDS ( Network IDS ) Se basan en el comportamiento de la red HIDS ( Host IDS ) Se basan en el comportamiento del servidor Según el abordaje de los algoritmos de detección Por plantilla o reglas (signature based) Por anomalía (anomaly based) Híbridos

68 Esta clasificación es debido a [Dacier et al, 1999] Método de detección Anomaly based y Signature based Comportamiento en la detección Pasivo y proactivo Localización de la fuente de auditoría NIDS y HIDS Frecuencia de uso Tiempo real y offline

69 Por plantilla o signature La información de auditoría que es analizada se compara con un conjunto predefinido de ataques (llamados plantillas o reglas o signatures). Ventajas Detección con bajo ratio de falsos positivos Identificación precisa del tipo de intrusión Protección inmediata De bajo consumo de recursos Desventajas Cada nuevo ataque requiere una actualización de la base de datos de plantillas No puede lidiar con ataques desconocidos o variaciones de los ya registrados (ataques polimórficos) La descripción de los ataques debe hacerse de forma muy precisa y detallada.

70 Por anomalía Se basan en que todas las actividades anómalas son maliciosas. Construyen un modelo del comportamiento normal, denominado perfil. Comparan entonces la información auditada con el perfil para establecer si existe o no una intrusión.

71 Detección por anomalía Ventajas Detección de ataques desconocidos Detección de ataques internos Es difícil para un atacante conocer a priori que actividad genera o no una alarma. Desventajas Generación de muchos falsos positivos El tiempo requerido para el entrenamiento El comportamiento de un ambiente monitoreado puede cambiar (luego del entrenamiento), por tanto se requiere re-entrenar. En el periodo de entrenamiento se puede incluir ataques.

72 Premisas de la detección por anomalía Una actividad intrusiva es un subconjunto de una actividad anómala. En un caso ideal coinciden. Pueden darse las siguientes combinaciones que caracterizan a un evento: Intrusivo pero no anómalo : falso negativo No intrusivo pero anómalo : falso positivo No intrusivo no anómalo: verdadero negativo Intrusivo y anómalo : verdadero positivo

73

74 Qué información necesitamos? Máquina origen Timestamp Método HTTP URI solicitado Paquete HTTP completo Un ataque puede encontrarse en: URI Cabecera HTTP del cliente Cookie En el cuerpo (consulta)

75 Detección por plantilla (signature) Es el método habitual y más sencillo de implementar. Dos principales detectores por signature existen en el mundo OpenSource - Snort (ww.snort.org) - mod_security (p/apache: Los de uso comercial son varios.

76 Detección por signature Ejemplo de una regla de SNORT para XSS Para un típico <script>alert(document.cookie)</script> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"web-misc cross site scripting attempt"; flow:to_server,established; content:"<script>"; nocase; classtype:web-application-attack; sid:1497; rev:6;) Para un típico ataque <img src=javascript> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"web-misc cross site scripting HTML Image tag set to javascript attempt"; flow:to_server,established; content:"img src=javascript"; nocase; classtype:web-application-attack; sid:1667; rev:5;)

77 Detección por signature Lo anterior puede ser evadido <a href="javascript#[code]"> <div onmouseover="[code]"> <img src="javas cript:[code]"> <xml src="javascript:[code]"> <img src=base64(amf2yxnjcmlwda==)>

78 Detección por signature Podemos mejorar usando una expresión regular /((\%3D) (=))[^\n]*((\%3c) <)[^\n]+((\%3e) >) Chequea la ocurrencia de : = seguido de uno o mas \n seguido de < o su equivalente hex. cero o mas / seguido de > o su equivalente hex.

79 Inconvenientes de la detección por signature Los desarrolladores asumen que los campos ocultos no cambian. Por tanto no puede detectar si hubo o no manipulación en estos campos. Por ejemplo, no puede escribirse una regla, cuando se cambia de un valor 200 a 2 (suponiendo que el campo sea precio).

80 Inconvenientes en la detección por signature(2) Ataques de fuerza bruta (password, identificadores, usuarios, etc). Ejemplo:

81 Inconvenientes en la detección por signature(3) No es posible indicar una regla que pueda detectar vulnerabilidades relacionados a la lógica de la aplicación. En algunos casos es preciso un mejor mecanismo. Considere el siguiente ejemplo y suponga que se encuentra en un mail o en un foro: <scri<s<script>crip>>alert(document.cookie) </scri</script>ip> Qué debería hacer el detector?

82 Detección por anomalía Suelen complementar los detectores por signature Una sola técnica no puede abarcar todos los posibles ataques. Normalmente se utilizan varias técnicas. Alguna técnicas utilizadas estan basadas en: Modelos estadísticos Técnicas de Machine Learning y Data Mining Computación inmunológica Procesamiento de señales Métodos basados en especificación Análisis de estados

83 Anomaly Detection of Web based Attacks (C. Kruegel & G. Vigna) 2003 ( University of California, Santa Barbara) Uno de los trabajos más citados en el área específica Modelo de Datos (solo la cadena de consulta)

84 Anomaly Detection of Web based Attacks (C. Kruegel & G. Vigna) Modelo de detección Utiliza seis modelos de detección que identifica una entrada anómala en un conjunto asociado a un programa particular. Cada modelo genera un valor de probabilidad que indica si la entrada guarda relación con el perfil normal. Para determinar el valor final (score) se usa la siguiente fórmula Cada modelo opera en dos fases: entrenamiento y detección

85 Anomaly Detection of Web based Attacks (C. Kruegel & G. Vigna) 2003 Modelos: Longitud Distribución de caracteres Inferencia estructural Enumerador Presencia o ausencia de atributos Orden de los atributos

86 Anomaly Detection of Web based Attacks (C. Kruegel & G. Vigna) 2003 Longitud Se basa en el hecho de que la longitud de ciertos atributos es fija o su variación es pequeña. Distribución de caracteres Se basa en el hecho de que los valores de los parámetros tienen una distribución similar de caracteres.

87 Anomaly Detection of Web based Attacks (C. Kruegel & G. Vigna) 2003 Inferencia estructural Se basa en el hecho de que muchos atributos pueden ser generados como cadenas generadas por una gramática regular. Construye una gramática probabilística (Modelo de Markov) Enumerador Se basa en el hecho de que los valores de los atributos pueden tomar un conjunto finito de constantes.

88 Anomaly Detection of Web based Attacks (C. Kruegel & G. Vigna) 2003 Presencia o ausencia de atributos Se basa en que el procesamiento es usualmente resultado de una alta regularidad en el número, nombre y orden de los parámetros. Se detecta si el conjunto de parámetros se encuentra en el conjunto normal observado en la etapa de entrenamiento. Orden de los atributos La lógica de una aplicación es usualmente secuencial y por tanto el orden relativo de los parámetros se mantiene aun cuando un parámetro es omitido en la consulta.

89 Anomaly Detection of Web based Attacks (C. Kruegel & G. Vigna) 2003 Capacidad de detección

90 Using Generalization and Characterization Techniques in the Anomalybased Detection of Web Attacks (Robertson, Kruegel & Kemmerer) 2006 Basado en Anomaly Detection of Web based Attacks Se dispuso un mecanismo de generalización mediante un modelo abstracto que encuentra anomalías iniciales y similares. Para cada modelo se establece una medida de similaridad. Incluye capacidad de caracterizar los ataques en los siguientes tipos utilizando algunas heurísticas: Directory traversal Presencia de los caracteres. y / XSS Elementos de JS o HTML SQL Inyection Elementos de SQL Buffer Overflow Caracteres no ASCII

91 Using Generalization and Characterization Techniques in the Anomaly-based Detection of Web Attacks 2006

92 Using Generalization and Characterization Techniques in the Anomaly-based Detection of Web Attacks 2006

93 Otros trabajos en el área Swaddler: An Approach for the Anomaly-based Detection of State Violations in Web Applications (2007) Basado en estado de ejecución de las aplicaciones. The Essence of Command Injection Attacks in Web Applications (2006). Orientado a inyección de código (XSS, SQL inyection, etc) Data Mining for Intrusion Detection: from Outliers to true Intrusions (2009) Utiliza técnicas de Data Mining y separación de agrupación mediante wavelets.

94 Otros trabajos en el área (2) Spectrogram: A Mixture-of-Markov-Chains Model for Anomaly Detection in Web Traffic (2009) Learning DFA Representations of HTTP for Protecting Web Applications (2007) Boosting Web Intrusion Detection Systems by Inferring Positive Signatures (2008)

95 IDS distribuidos. Correlación de alarmas distribuida. Métricas globalmente aceptadas para determinar la eficiencia de los IDS. Conjunto de datos estandarizado para las pruebas. Dinamicidad de los cambios en las aplicaciones Automatización

96

97 Detección de intrusión en aplicaciones web Detector basado en anomalía En principio utilizando algunas aspectos del trabajo de Robertson & Kruegel. Utilización de técnicas del área de procesamiento de señales para detección de anomalías (ondeletas o wavelets). Trabajo presentado en el CNMAC 2009 (Congreso Nacional de Matemática Aplicada y Computacional, Cuiaba-BR)

98 En el marco de un proyecto conjunto de investigación con la Universidad Federal de Santa María (UFSM). Actualmente en desarrollo: Infraestructura de captura de datos para análisis real (sniffer). Reporte técnico sobre uso de transformadas wavelets para detección de longitudes anómalas en cadenas de consulta HTTP.

99