Análisis Estático de Código para Detección de Vulnerabilidades en Aplicaciones Web Pablo E. (Fidel) Martínez López, Dr.

Presentación del tema: "Análisis Estático de Código para Detección de Vulnerabilidades en Aplicaciones Web Pablo E. (Fidel) Martínez López, Dr."— Transcripción de la presentación:

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 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 ¿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! “SELECT * FROM users WHERE email=′juan@host′ AND pincode=123 OR 0=0”; “123 OR 0=0”

14 Sistemas de Tipos Estáticos

15 ¿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 1. relaciones funcionales (o no) a cada término le corresponde un único tipo 2. 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 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 = xmap f [] = [] map f (x:xs) = f x : map f xs

26 Sistema Hindley-Milner Las reglas fundamentales son 4: Funciones Aplicación Generalización Instanciación x ::     x ::    e ::  2   1    e’ ::  2  e e’ ::  1   , x ::  2  e ::  1  x.e ::  2   1    e ::   FV(  )  e :: .     e :: .   e ::  [  :=  ’]  

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 Hindley-Milner con Restricciones Los juicios tienen restricciones La regla de generalización es ahora Simplificaciones posibles  Dependen del álgebra X  E.g. C  D,  e ::   FV(C)  FV(  )  C  a.D,  e :: .D     .  <   <  se puede simplificar a <<

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 Hindley-Milner con Restricciones Gráficamente: Parte 1 Parte 2 Inferencia de tipos programa Tipo (con restricciones) Resolución de restricciones restricciones Solución

32 Grammar-Based Analysis

33 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 |    -- relación de subtipado | r   -- relación de derivación | C  C-- conjunción de restricciones r ::=  |  | a | r ++ r -- similar a producciones -- (siendo a un terminal)

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

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

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 -> “ ” ++ render l ++ “ ” ++ “ ” ++ render r ++ “ ”

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

43 Grammar-Based Analysis Pero… ¿ render t produce código HTML? ¡Usamos resolución de restricciones!  Se usa la gramática G HTML 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 G HTML, 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 ¿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 G V 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”; “SELECT * FROM users WHERE email=′juan@host′ AND pincode=123 OR 0=0”; Terminales seguros Terminales inseguros

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 G V 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

51 Conclusiones Los sistemas de tipos son una herramienta muy versátil para diversos propósitos La investigación en este área está en auge y hay interés creciente en estos sistemas La industria y la academia pueden colaborar con éxito  Requiere resignificar muchos códigos implícitos de comunicación…

52 Bibliografía Benjamin C. Pierce. Types & Programming Languages. The MIT Press, 2002 John C. Reynolds. Theories of Programming Languages. Cambridge University Press, 1998. Pablo E. Martínez López. Static type systems: from specification to implementation. Chapter 11 of Verification, Validation and Testing in Software Engeneering. Aristides Dasso and Ana Funes (eds.). Idea Group Publishing, 2005.

53 Bibliografía M. Odersky, M. Sulzmann, and M. Wehr. Type inference with constrained types. Theory and Practice of Object Systems, 5(1):35-55, 1999. Peter Thiemann. Grammar-based analysis of string expressions. In Proceedings of the 2005 ACM SIGPLAN international workshop on Types in languages design and implementation, pp. 59- 70. ACM Press, 2005.