Análisis Estático de Código para Detección de Vulnerabilidades en Aplicaciones Web

1. Análisis Estático de Código para Detección de Vulnerabilidades en Aplicaciones Web Pablo E. (Fidel) Martínez López, Dr.fidel@lifia.info.unlp.edu.ar

2. “The study of type systems – and of programming languages form a type-theoretical perspective – has become an energetic field with major applications in software engineering, language design, high-performance compiler implementation, and security.” Benjamin C. Pierce Types and Programming Languages

3. Resumen de temas • Proyecto: “Seguridad en aplicaciones web” • Problema: Detectando vulnerabilidades • La técnica: • Sistemas de tipos estáticos • Sistemas Hindley-Milner con restricciones • Grammar Based Analysis • Propuesta: GBA y vulnerabilidades • Conclusiones

4. Seguridad en Aplicaciones Web

5. Seguridad en Aplicaciones Web • Proyecto de investigación conjunta entre • LIFIA, Universidad Nacional de La Plata • CORE Security Technologies S.A. • Financiación • ANR de la Agencia de Investigaciones Científicas y Tecnológicas • Proyecto NA 080/04 “Plataforma híbrida de seguridad para protección de aplicaciones WEB”

6. Seguridad en Aplicaciones Web • Equipo • 6 investigadores por el LIFIA • 2 senior • 4 juniors • 4 investigadores por CORE (más personal de apoyo) • Duración del proyecto • 1 año

7. Seguridad en Aplicaciones Web • Etapas • Conocimiento de los equipos • Familiarización con problemas y técnicas • Análisis de posibles soluciones y elección de 2 alternativas • Basadas en análisis estático de código • Diseño e implementación de las elegidas • Ejecución Simbólica de código JAVA • Grammar-Based Analysis extendido (sistema de tipos estático especializado)

8. Detectando Vulnerabilidades

9. Detectando Vulnerabilidades • ¿Qué es una vulnerabilidad en una aplicación web? • Un punto donde un atacante puede usar el sistema en forma no especificada, e.g. • tener acceso a información confidencial • realizar operaciones privilegiadas, etc. • El proyecto se concentró en inyección de código (source-code injection)

10. Detectando Vulnerabilidades • Inyección de Código • Se leen parámetros ingresados por un usuario en una interface web (como strings) • Se componen con otros strings para armar código • Se ejecuta el código producido de esta manera • ¿Cómo sabemos que lo ingresado es siempre lo esperado?

11. Detectando Vulnerabilidades • Ejemplo • Si el atacante provee en $email ¡se produce un ataque! get($email); get($pincode); $query = “SELECT * FROM users WHERE email=′” . $email . “′ AND pincode=” . $pincode; $result = mysql_query($query); “juan@host′ OR ′0′=′1”

12. Detectando Vulnerabilidades • Ejemplo (cont.) • Notar el uso de las comillas simples • El atacante puede introducir operadores lógicos donde sólo se esperaba un email… • Query producido: • ¡Ignora el PIN! “SELECT * FROM users WHERE email=′juan@host′OR ′0′=′1′ AND pincode=123”;

13. Detectando Vulnerabilidades • Ejemplo (cont.) • Otra posibilidad es que provea en $pincode • Query producido: • ¡Obtiene todas las filas de la tabla! “123 OR 0=0” “SELECT * FROM users WHERE email=′juan@host′AND pincode=123 OR 0=0”;

14. Sistemas de Tipos Estáticos

15. Sistemas de Tipos Estáticos • ¿Qué son? • herramientas para determinar propiedades de programas sin ejecutarlos • asocian información a cada parte de un programa • se basan en el texto del programa, teniendo en cuenta la semántica

16. Sistemas de Tipos Estáticos • Características generales • estáticos • no ejecutan el programa • decidibles (en general) • hay un algoritmo que calcula la propiedad • ALTERNATIVA: tipos dependientes • no decidibles • asistentes para la construcción de programas correctos • pueden requerir anotaciones del usuario o no • diferentes estilos de programación

17. Sistemas de Tipos Estáticos • Estilos de diseño del sistema • A la Curry (pej. PHP) • términos sin tipo • semántica sobre ellos • el sistema de tipo que elimina (ciertos) programas erróneos • A la Church (pej. JAVA) • términos tipados • semántica basada en los tipos

18. Sistemas de Tipos Estáticos • Presentaciones del sistema • implícita (términos sin anotaciones de tipos) • explícita (términos con anotaciones de tipos) • Históricamente • los implícitos se presentan a la Curry • los explícitos se presentan a la Church • Es común mezclar estilo y presentación

19. Sistemas de Tipos Estáticos • Sistemas a la Curry • lenguaje de términos • semántica sobre este lenguaje • lenguaje de tipos • relación entre términos y tipos • Propiedades fundamentales • un término con tipo no tiene ciertos errores • el tipo describe propiedades del término

20. Sistemas de Tipos Estáticos • Método para especificar la relación • juicios • (esquemas de) reglas de derivación • árboles de derivación • Propiedad básica • juicio válido  árbol de derivación para él

21. Sistemas de Tipos Estáticos • Características de un sistema dado • relaciones funcionales (o no) • a cada término le corresponde un único tipo • relaciones dirigidas por sintaxis (o no) • hay una regla por cada construcción del lenguaje • Implicaciones • Para 1. los algoritmos son casi triviales • Para 2. los algoritmos son recursivos

22. Sistemas de Tipos Estáticos • ¿Y si el sistema no es funcional o dirigido por sintaxis? • Diseñamos uno equivalente que lo sea • ¡Debe demostrarse en qué sentido son equivalentes! • Típicamente: • relación entre diferentes tipos • para un término, establecer la relación entre la salida del algoritmo y sus tipos

23. Sistemas de Tipos Estáticos • Importancia • ventajas para los programadores • chequeo de errores comunes • documentación rudimentaria • posibilidades de optimización al compilar • desarrollos posteriores basados en ellos • Types & Effects • Type Specialization • Grammar Based Analysis

24. Sistema Hindley-Milner

25. Sistema Hindley-Milner • Para lenguajes funcionales • Sistema de tipado implícito • Tipos básicos • Tipos compuestos (¡funciones!) • Polimorfismo paramétrico • Cuantificación universal de variables de tipo en el nivel más externo, e.g. id :: a.aamap :: a.b.(ab)[a] [b]id x = x map f [] = [] map f (x:xs) = f x : map f xs

26. G e :: t2t1Ge’ :: t2 • G e e’ :: t1 • G, x :: t2e :: t1 • Gx.e :: t2t1      • x :: tG • G x :: t • G e :: a.t • G e :: t[a:=t’] • G e :: ta FV(G) • G e :: a.t      Sistema Hindley-Milner • Las reglas fundamentales son 4: Funciones Aplicación Generalización Instanciación

27. Hindley-Milner con Restricciones • Diversas extensiones usan restricciones • Registros • Overloading (polimorfismo ad-hoc) • Subtyping • Todas estas extensiones desarrollan • Teorías de restricciones similares • Algoritmos de inferencia similares

28. Hindley-Milner con Restricciones • Sistema HM(X) • Marco general para estas extensiones • Enriquece el sistema HM con un parámetro X • X es un álgebra (cilíndrica) de restricciones(con un operador  de proyección) • Ejemplos • X = álgebra de Herbrand  Hindley-Milner • X = sistema de subtipos  HM con subtipos • Otros: overloading, records, BTA, GBA, etc.

29. CD, G e :: ta FV(C)FV(G) • Ca.D, G e :: a.Dt   • b.a<b  b<g • a<g se puede simplificar a Hindley-Milner con Restricciones • Los juicios tienen restricciones • La regla de generalización es ahora • Simplificaciones posibles • Dependen del álgebra X • E.g.

30. Hindley-Milner con Restricciones • El trabajo se divide en 2 partes: • Inferencia de tipos • Colectar restricciones • Similar a dar una especificación del problema • Resolución de restricciones • Similar a implementar una solución que satisfaga la especificación • El algoritmo de resolución depende de qué restricciones se usan

31. programa restricciones Inferencia de tipos Resoluciónde restricciones Tipo (con restricciones) Solución Hindley-Milner con Restricciones • Gráficamente: Parte 1 Parte 2

32. Grammar-Based Analysis

33. Grammar-Based Analysis • Motivación • Strings usados en contextos inapropiados(e.g. sustituyendo a tipos en lenguajes de scripts) • Descriptores de estilos • HTML y XML • Expresiones Xpath • Sentencias SQL

34. Grammar-Based Analysis • ¿Cuál es el problema? • ¡El mantenimiento! • Los strings con semántica • Pueden conducir a errores en runtime • Constituyen puntos de ataque para crackers • No son prevenidos por los sistemas de tipos tradicionales • Son difíciles de testear exahaustivamente

35. Grammar-Based Analysis • Peter Thiemann desarrolló una instancia de HM(X) • Propósito original de Thiemann: • Aliviar mantenimiento y debugging de programas existentes • NO un framework para construir programas • Se lo puede adaptar para detección de vulnerabilidades en aplicaciones web

36. Grammar-Based Analysis • Enfoque: • Se enriquece el sistema de tipos • Con tipos String() tq  es una variable de lenguaje • Con un álgebra de restricciones que predican sobre dichas variables • La inferencia provee las restricciones que satisfacen los strings producidos por el programa • La resolución es paramétrica respecto de un lenguaje dado

37. Grammar-Based Analysis • Resolución de restricciones en GBA • Se provee una gramática de referencia G • Se determina cuáles de las asignaciones de los no-terminales de G a variables de lenguaje satisfacen las restricciones • Estos no-terminales aproximan la forma de los strings producidos

38. Grammar-Based Analysis • Las restricciones tienen la forma: C ::= true-- siempre verdadera | tt -- relación de subtipado | r -- relación de derivación | CC -- conjunción de restricciones r ::=  | e | a | r++r -- similar a producciones -- (siendo a un terminal)

39. Gw :: .(w)String()  • G e1 :: String(1) G e2 :: String(2) • G e1++e2 :: 12.(1++2)String()    • 12 • String(1)String(2) Grammar-Based Analysis • Algunas reglas de tipado • y de simplificación

40. programa Restricciones sobre ‘s Gramática de referencia G Inferenciade tipos Resoluciónde restricciones Tipo (con restricciones sobre ’s) Asignaciones válidas de no-terminales de G a ‘s Grammar-Based Analysis • GBA gráficamente: Parte 1 Parte 2

41. Grammar-Based Analysis • Ejemplo (en Haskell) • ¿Produce render código HTML válido? • ¡El tipo en Haskell no lo indica! data ForkTree = Tip Int | Fork ForkTree ForkTree render :: ForkTree -> String render t = case t of Tip s -> int2string s Fork l r -> “<ul><li>” ++ render l ++ “</li>” ++ “<li>” ++ render r ++ “</li></ul>”

42. C1 = (0++21  1++21  …  1  12) • int2string :: 12.(C1)  Int  String(1)  • C2 = (<ul><li>++++</li><li>++++</li></ul>1) • render t :: 12.(C2C1)String()  Grammar-Based Analysis • Ejemplo (cont.) • Asumiendo que el tipo GBA de int2string es • Con GBA, el tipo asignado para cada t fijo es

43. Grammar-Based Analysis • Pero… ¿render t produce código HTML? • ¡Usamos resolución de restricciones! • Se usa la gramática GHTML de HTML como gramática de referencia • Se realiza la resolución (cuyo mecanismo es similar al parsing) • Si todas las variables de lenguaje pueden asignarse a algún no-terminal de GHTML, entonces la respuesta es sí. Si no, es no.

44. Grammar-Based Analysis • Algunas deficiencias • ¿Por qué tener una gramática de referencia? • Decidir cuáles lenguajes satisfacen las restricciones es indecidible en general • Las gramáticas de referencia tienen que ser orientadas a caracteres (y no a tokens) • Es preferible que sean ambiguas • Aún no manejan operaciones de deconstrucción de strings

45. GBA y Vulnerabilidades

46. GBA y Vulnerabilidades • ¿Cómo usar GBA para detectar injections? • Enriquecer el lenguaje • Para poder escribir programas con vulnerabilidades • ¡Implica extender la teoría! • Luego, se usan dos copias de los terminales • Terminales seguros – utilizados en el programa • Terminales inseguros – provistos por el atacante • Y se provee una gramática GV por cada tipo de vulnerabilidad V

47. GBA y Vulnerabilidades • Terminales seguros e inseguros – ejemplo “SELECT * FROM users WHERE email=′juan@host′OR ′0′=′1′ AND pincode=123”; Terminalesseguros Terminalesinseguros “SELECT * FROM users WHERE email=′juan@host′AND pincode=123 OR 0=0”;

48. GBA y Vulnerabilidades • ¿Cómo usar GBA para detectar esto? (2) • La inferencia provee información sobre cómo se forman los strings usados para queries u otros tipos de ejecuciones no seguras • La resolución contra GV establece si el programa tiene la vulnerabilidad V • ¡Podría extenderse para extraer instancias de ataques a partir de la gramática!

49. GBA y Vulnerabilidades • Ventajas • Framework único, no dependiente del conjunto de vulnerabilidades • Posibilidad de armar instancias de ataques • Desventajas • La extensión a lenguajes orientados a objetos (e.g. JAVA) es compleja • Aún en etapa experimental

50. Conclusiones y Bibliografía