SOFTWARE SEGURO. Proyecto final de carrera. Departament d Enginyeria Informàtica i Matemàtiques

Transcripción

1 Departament d Enginyeria Informàtica i Matemàtiques Proyecto final de carrera SOFTWARE SEGURO AUTORA: Yanina Di Sipio TUTOR: Pere Millán Marco DIRECTOR: Jonatán Cortés FECHA: 08/06/2010

2 Índice EMPRESA 1. Descripción de la empresa Ubicación A qué se dedica Plantilla 3 PROYECTO 2. Proyecto Introducción Ubicación del proyecto dentro de la empresa Objetivos dentro de la empresa 7 DESCRIPCIÓN 3. Descripción del trabajo realizado Objetivo del proyecto Fases del proyecto Especificación del proyecto Diseño Desarrollo Seguridad en desarrollo Java Modelo de seguridad Java Posibles ataques y vulnerabilidades en Java Análisis estático Otros analizadores estáticos LAPSE Test de verificación Cálculo de Riesgo Evaluación Evaluación inicial Evaluación final Recursos utilizados 40 APORTACIONES 4. Aportaciones Aportaciones del proyecto Aportaciones de los estudios realizados al proyecto 46 CONCLUSIONES 5. Conclusiones Conclusión general Conclusión final 47 2

3 Empresa 1. Descripción de la empresa 1.1 Ubicación Figura 1. Logotipo de d-core La empresa d-core Network Iberia a member of T-Systems Iberia, está situada en la provincia de Tarragona, ciudad de Reus. Su dirección es: Camí de Valls 81-87, Reus. 1.2 A qué se dedica d-core (The Software Core in Europe) es el nombre en la empresa T-Systems, una unidad de Systems Integration, dedicada al desarrollo y mantenimiento de aplicaciones y productos. A nivel internacional se denomina ADSF (Application Development & Service Factory) Empresa de desarrollo de Software. d-core Network es uno de los ejes del proyecto de transformación de T-Systems Iberia. Gracias a d-core, aumentarán las capacidades para conseguir grandes proyectos, que son clave para conseguir un liderazgo en el Sector Público, Financiero y otros. Su enfoque es agregar a los elementos de servicios de Sistemas de Integración, mayor calidad, mayores servicios, como: variedad de idiomas, variedad en tecnología, etc. El objetivo es estar preparada ante el aumento de la demanda de aplicaciones del mercado. Los objetivos de la empresa son: Facilitar el crecimiento de su empresa madre, T-Systems. Mejorar su rendimiento. Conseguir una mayor satisfacción del cliente. Satisfacción del empleado. Mejorar la calidad de los productos desarrollados en la empresa. 1.3 Plantilla El plan de desarrollo profesional sustenta los recursos humanos de d-core, creando una organización competitiva, con altos niveles de rendimiento, facilitando la obtención de los objetivos de la empresa. Además el plan de mejora profesional es un elemento diferenciador y motivador que atrae a nuevos y mejores profesionales y al compromiso de aquellos que ya están incorporados. 3

4 El proceso de mejora profesional está basado en un proceso de mejora continua: Identificación de carencia de conocimientos: para cada perfil y para cada grupo de trabajo, con el objetivo de permitir la preparación de planes de acción correctivos. Plan de formación: publicación de un plan de formación para cada uno de los roles en d-core, para esforzar, aprender y reafirmar las habilidades técnicas y profesionales con certificaciones que acrediten dicha formación. Plan de carrera: publicación de un plan de carrera para cada rol, ofreciendo una clara percepción del futuro profesional de cada persona en d-core. Plan de evaluación: evaluación continua del rendimiento profesional mediante el diálogo entre profesionales para asegurar la motivación y el crecimiento profesional basado en expectativas y hechos. Actualmente d-core tiene diferentes grupos de trabajo y desarrollo de proyectos en cuatro diferentes tecnologías:.net, Java, Host y SAT, y consta de una plantilla de 80 personas en la oficina de Reus. La plantilla de los proyectos consta de las siguientes figuras más importantes: Analistas funcionales Ingenieros software Desarrolladores Proyecto 2. Proyecto 2.1 Introducción En esta sección se establecerán los objetivos principales de este PFC. También se introducirán y analizarán las últimas tendencias en la seguridad software. Estado del Arte sobre la Seguridad en las Aplicaciones Web Las aplicaciones Web se han convertido en los últimos años en un apoyo crucial en casi todas las líneas de negocio. Quedan muy pocas cosas que no se puedan hacer en Internet. Conceptos como comercio electrónico, redes sociales, servicios Web, educación on-line, etc. dominan el mundo de las nuevas tecnologías. Los datos manejados por las aplicaciones Web también son cada vez más sensibles. Los datos personales, financieros, médicos necesitan una protección muy alta. De ahí que la seguridad en las aplicaciones Web sea cada vez más importante. Según informes sobre seguridad de CSI/FBI, los ataques contra las aplicaciones Web ocurren cada vez más a menudo. A pesar de que en los últimos años su frecuencia había bajado, desde hace un par años cada vez ocurren más abusos en las aplicaciones Web. Se repiten ataques a gran escala, como el de la intrusión en una base de datos de la Universidad de California, ocurrido en el año Los atacantes consiguieron acceder a una base de 4

5 datos sobre salud y robar la información personal de hasta estudiantes, o ataques como el que recibió Google este año [14], que ha sido calificado como ataque sofisticado. Por otro lado, el informe de CSI/FBI indica que cada vez existe más preocupación sobre la seguridad de entornos Web. Las organizaciones empiezan a incluir los procedimientos de seguridad en los ciclos de desarrollo de software. Sin embargo, como se puede observar en la Figura 2, sólo la mitad de las organizaciones emplea los procedimientos formales. Software Development Process in your Organization Figura 2: El proceso de desarrollo de software en las organizaciones [17] La Figura 3 muestra las fases del ciclo de vida de software de calidad. Se observa que la seguridad y el análisis de los riesgos forman parte de este desarrollo. Una parte importante es el análisis estático del código, cuyo fin es detectar errores de diferentes tipos. Figura 3: Fases del ciclo de vida software [16] El rendimiento del análisis estático de código es inversamente proporcional al tamaño del código. Si para un código pequeño sería todavía viable realizar el análisis manual, para un código grande sería altamente ineficiente. Por ello es necesario utilizar las herramientas diseñadas para realizar este análisis. Existen muchas herramientas open source, para realizar el análisis estático de código basado en aspectos de seguridad, sin embargo la mayoría son para el lenguaje C, que se considera altamente inseguro. Dado que las Aplicaciones Web que se desarrollan en la empresa son en lenguaje Java, utilizando la tecnología J2EE, es importante asegurar la seguridad en este entorno de desarrollo. Aunque el lenguaje Java se considere más seguro que C, sigue siendo vulnerable a muchos ataques de varios tipos. Por tanto existe una necesidad de herramientas de análisis 5

6 estático con el fin de garantizar la seguridad para el código de Java. En este proyecto se estudia la herramienta Lapse. Para que estás herramientas sean eficaces también es necesario que las personas que integran un proyecto determinado, tengan todo el conocimiento necesario para entender y saber sobre estas vulnerabilidades. En esta fase se centra este proyecto. El objetivo principal es educar a desarrolladores, ingenieros y analistas funcionales sobre seguridad software. 2.2 Ubicación del proyecto dentro de la empresa La organización de los proyectos en la empresa d-core se estructuran según se muestra en la figura 4. Existe una dirección y un coordinador de proyectos generales. Cada proyecto tiene asignado un jefe de proyecto, donde su función es coordinar las actividades de desarrollo de software y la interacción con los responsables de la empresa cliente. Dirección General Coordinador de Proyectos Jefe de Proyecto Jefe de Proyecto Jefe de Proyecto Analistas Funcionales Analistas Funcionales Analistas Funcionales Ingenieros Ingenieros Ingenieros Desarrolladores Desarrolladores Desarrolladores Figura 4. Estructuración de recursos humanos en proyectos de d-core La plantilla de los proyectos consta de las siguientes figuras: Analistas funcionales: son el vínculo entre el usuario y el área informática. Sus tareas son: elaborar el análisis funcional (documento de requisitos) de las nuevas aplicaciones, así como actualizar y mejorar las existentes. Ha de controlar, analizar y supervisar el desarrollo funcional de las aplicaciones, asegurando su correcta explotación y óptimo rendimiento. También ayuda a los diferentes usuarios (clientes), realiza un trabajo de asesoramiento y capacitación, con la finalidad de evitar cualquier problema que pueda surgir con los programas. 6

7 Ingenieros de Software: hay tres rangos: Junior, Confirmed y Sénior Son los que conocemos como analistas y analistas programadores. Si los analistas funcionales se basan en lo que se ha de hacer, los ingenieros se encargan de cómo hacerlo. Reciben el documento funcional de los analistas funcionales y a partir de él elaboran los planos de la aplicación, diseño de base de datos, diagramas de clases, etc. También trabajan en tareas de programación, dando soporte a los programadores, cuando lo necesitan. Desarrolladores: son los programadores. Dentro de este sector de la empresa también hay tres rangos, como es el caso de los Ingenieros de Software: Junior, Confirmed y Sénior. Reciben las especificaciones técnicas de los ingenieros de software y transforman sus esquemas y diseños en aplicaciones finales. Siguiendo esta estructura, el proyecto está enfocado a todos los que trabajan en la empresa, independientemente del proyecto que realicen. A partir de una visión como programador se debía investigar y llevar a cabo las prácticas oportunas, para colaborar con un punto más en el eslabón hacia la seguridad informática. En este proyecto participaron: una programadora (yo), un jefe de proyecto (tutor dentro de la empresa), un coordinador de proyectos y dirección general (jefes de la empresa). 2.3 Objetivos dentro de la empresa El objetivo principal del proyecto dentro de la empresa se puede enumerar de la siguiente manera: Crecimiento en seguridad Información actual sobre seguridad software. Aprender más sobre la seguridad en aplicaciones Web: o Tener documentos de información que estén orientados exclusivamente a la actividad que se desarrolla dentro de la empresa. o Poseer herramientas para el análisis de código. Evaluar el nivel de seguridad de sus proyectos. Una manera más de formar a sus trabajadores. Descripción 3. Descripción del trabajo realizado 3.1 Objetivo del proyecto Después de un análisis inicial de la seguridad en las aplicaciones Web y, más en concreto, de los entornos de desarrollo Java surgen los objetivos principales de este proyecto. Con este PFC se pretende: Estudiar y desarrollar un documento con los aspectos de seguridad de Java que afectan a las Aplicaciones Web. 7

8 Se analizarán las amenazas más comunes y frecuentes para las aplicaciones Web. Especialmente se tendrán en cuenta las aplicaciones Web creadas con la tecnología J2EE. Se estudiarán los aspectos de seguridad Java y sus vulnerabilidades más extendidas. Estudiar las técnicas de análisis de seguridad estático sobre desarrollos Java. Se analizará el proyecto LAPSE, teniendo en cuenta sus antecedentes, funcionamiento, implantación y resultados que obtiene. Estudiar y desarrollar un método de cálculo de riesgo. Se estudiará y desarrollará el método de cálculo de riesgo más efectivo para la empresa, el cual permitirá calcular un nivel de riesgo personalizado para cada proyecto. Desarrollar una guía de verificación de control. Partiendo del documento diseñado, se va a construir una herramienta tipo test a nivel teórico para determinar el nivel de riesgo de cada proyecto. Es un método más de control final que una vez terminado quedará para el uso del Ingeniero. Los objetivos enumerados arriba, son los objetivos generales del proyecto. De cada objetivo general se derivan unas fases de proyecto que a su vez implican unos objetivos más específicos. En la siguiente sección se describen las fases del proyecto y sus objetivos. 3.2 Fases del proyecto FASE 1 Tarea 1 Tarea 2 Objetivos Etapa inicial del proyecto en la empresa Reunión y comprensión del enfoque del proyecto dentro de la empresa. Lectura y aprendizaje de Documentación inicial. Entender el funcionamiento de la empresa para saber cómo enfocar el proyecto. Leer y comprender Documentación inicial otorgada por la empresa para iniciar el estudio de software de seguridad. Tabla 1: Descripción de la fase 1 del PFC FASE 2 Tarea 1 Tarea 2 Tarea 3 Objetivos Estudio inicial del marco teórico Recopilación de documentación sobre vulnerabilidades en aplicaciones Web. Recopilación de documentación de técnicas de análisis de código. Recopilación de documentación de herramientas de análisis de código. Conocer y entender el funcionamiento de las vulnerabilidades comunes en las aplicaciones Web. Entender diferentes técnicas de análisis estático de código y sus aplicaciones. Conocer las herramientas open source para el análisis estático de código para encontrar vulnerabilidades de seguridad. Tabla 2: Descripción de la fase 2 del PFC 8

9 FASE 3 Tarea 1 Tarea 2 Objetivos Elaboración del documento Vulnerabilidades - J2EE Filtrar la información actual, necesaria y adecuada para la empresa. Desarrollar un documento con las principales vulnerabilidades en Java. Desarrollar el documento Vulnerabilidades J2EE : con las definiciones, descripciones, cómo detectar si se es vulnerable, cómo protegerse, la mejor verificación según la vulnerabilidad y links de ejemplos y referencia. Tabla 3: Descripción de la fase 3 del PFC FASE 4 Tarea 1 Tarea 2 Tarea 3 Tarea 4 Objetivos Elaboración de un modelo de cálculo de riesgo Recopilación de información para desarrollar un modelo de cálculo de riesgo. Elaboración del modelo. Incluir sus técnicas y descripción en el documento Vulnerabilidades J2EE. Desarrollar una herramienta de verificación a partir de este modelo. Obtener un modelo de cálculo de riesgo para determinar el nivel del mismo en cada proyecto. Desarrollar una herramienta para el ingeniero que sea de verificación de seguridad, que se adapte a cada proyecto y que integre este modelo. Tabla 4: Descripción de la fase 4 del PFC FASE 5 Tarea 1 Tarea 2 Tarea 3 Objetivos Estudio de un método de análisis estático Lectura de la documentación del método de análisis estático propuesto por el grupo SUIF. Estudio detallado del proyecto LAPSE. Elaboración de un documento-guía para usuarios de la herramienta LAPSE. Entender en detalle el método de análisis estático de código sensible al contexto, propuesto por el grupo SUIF. Conocer el análisis empleado en el proyecto LAPSE y los modelos de descripción de vulnerabilidades que utiliza e integrarlo a la empresa. Desarrollar un documento de guía para usuarios de la herramienta LAPSE, con casos prácticos, donde los proyectos son propios de la empresa. Tabla 5: Descripción de la fase 5 del PFC 9

10 FASE 6 Tarea 1 Tarea 2 Tarea 3 Objetivos Estudio práctico Instalación y configuración del proyecto a estudiar. Entender el funcionamiento del proyecto a estudiar. Realizar el análisis de código. Instalar y configurar en mi ordenador un proyecto de la empresa. Comprender el funcionamiento y el código para saber posteriormente cómo realizar un cambio o arreglar una vulnerabilidad. Hacer un análisis manual, aplicar la herramienta LAPSE y finalmente aplicar la herramienta de verificación final. Tabla 6: Descripción de la fase 6 del PFC FASE 7 Tarea 1 Tarea 2 Tarea 3 Objetivos Etapa final del proyecto en la empresa Redactar un documento que explique en detalle los resultados obtenidos en el análisis del caso práctico. Incluir en el documento las correcciones hechas en el caso práctico y futuros puntos a tener en cuenta dentro del desarrollo de un proyecto. Reunión final con la empresa. Redactar un informe donde se encuentren todos los resultados obtenidos en el caso práctico, tanto con la herramienta LAPSE, cómo con la herramienta de verificación final que te permite obtener el nivel de riesgo final del proyecto. Corregir y marcar los puntos donde se modificó el proyecto y por qué. Resumen de los puntos a tener en cuenta en el desarrollo de los próximos proyectos. Reunión final: entrega final del proyecto de investigación de Software de Seguridad a la empresa. Tabla 7: Descripción de la fase 7 del PFC FASE 8 Tarea 1 Tarea 2 Objetivos Redacción de la memoria del proyecto Redactar el documento que explique en detalle las tareas realizadas dentro de la empresa. Reunión final con mi tutor y presentación del proyecto. Crear el entregable final de este PFC a la Universitat Rovira i Virgili. Tabla 8: Descripción de la fase 8 del PFC 10

11 3.3 Especificaciones del proyecto El documento debía incluir información referente a Software de seguridad. Si bien la seguridad en la Ingeniería de Software es un tema amplio, el documento debía estar enfocado al diseño y desarrollo de aplicaciones Web en J2EE. Las principales especificaciones del documento eran: -Principales vulnerabilidades: Definición. Descripción. Cómo detectar que el código es vulnerable. Cómo protegerse. Cómo verificar la seguridad. Ejemplos y referencias. -Modelo de cálculo de riesgo. -Clases de técnicas. -Mejores prácticas: Para arquitectos y diseñadores. Para desarrolladores. Para dueños de aplicaciones. -Herramientas de testeo. -Caso práctico. -Referencias. La herramienta de verificación final debía estar enfocada al Ingeniero que es el responsable de testear cada proyecto realizado y de asegurar su calidad, por lo que esta herramienta debía incluir todos los puntos de vulnerabilidades más importantes del documento, el modelo de cálculo de riesgo y como resultado debía describir el nivel de seguridad de un proyecto. Las principales especificaciones de la herramienta eran: -Un cuestionario tipo checklist dirigido a Ingenieros. -Adaptable al tipo de empresa y a cada proyecto. Estudiar una herramienta de análisis estático de código para la seguridad Web en lenguaje Java. Esta herramienta debía encontrarla, luego debía estudiarla y proponerla a la empresa para su aceptación. Una vez aceptada debía incluirla en el estudio de un proyecto, realizar un manual y definir futuros cambios si la herramienta era de código abierto. Las principales especificaciones de la herramienta eran: -Para lenguaje Java. -De fácil utilización. -De código abierto. 3.4 Diseño Se ha diseñado un documento para educar a desarrolladores, diseñadores e Ingenieros sobre las consecuencias de las vulnerabilidades más comunes encontradas en aplicaciones Web. Provee métodos básicos para protegerse de dichas vulnerabilidades, un gran comienzo para un programa de seguridad en programación segura. 11

12 Este proyecto trata la seguridad actual, pero deja claro que la seguridad no es un evento único, dado que es insuficiente programar de manera segura sólo una vez, dado que a medida que pasa el tiempo aparecen nuevas amenazas. Una iniciativa de programación segura debe abordar todas las etapas del ciclo de vida de un programa. Las aplicaciones Web seguras sólo son posibles cuando se utiliza un SDLC seguro. Los programas seguros son seguros por diseño, durante el desarrollo, y por defecto. Existen al menos 300 problemas que afectan la seguridad general de una aplicación Web. Este documento filtra algunos problemas de vulnerabilidad, los más importantes en 2010 y que sólo tratan la fase de desarrollo. La metodología descrita en este proyecto orienta estas vulnerabilidades hacia descubrimientos realizados por la comunidad de investigadores de seguridad. Este patrón de descubrimiento es similar a los métodos de ataque real, en particular en lo que se refiere a atacantes principiantes ( Script Kiddy ). La protección del software descrita en este documento ofrece un mínimo de protección contra las formas más comunes de ataque, pero lo que es más importante es que ayudará a fijar un curso para mejorar la seguridad del software en la empresa. Se ha diseñado un manual de usuario con toda la información y los pasos a seguir para instalar y utilizar de manera correcta una herramienta de análisis estático. Para realizar la herramienta de verificación final, se ha diseñado una guía de preguntas a contestar según el proyecto que se esté testeando. Consta de diez preguntas orientadas al Ingeniero, responsable de la evaluación final de un proyecto en la empresa. Estas preguntas engloban las diez ideas principales del documento. Se ha implementado de manera que el cuestionario sea una verificación rápida de la seguridad de un proyecto en concreto y permita tener un resultado de riesgo de dicho proyecto. A partir del resultado de Riesgo, el ingeniero decide el siguiente paso, pero el documento refleja también qué hacer si el Riesgo fuera muy alto. 3.5 Desarrollo En esta sección se describen las cuestiones y conceptos estudiados en el análisis de este trabajo. Parte de esta información pertenece al documento creado para d-core. Primero se analiza la seguridad de la tecnología Java y las vulnerabilidades que puede poseer una aplicación creada con esta tecnología [3]. Se estudia también el concepto de análisis estático para encontrar vulnerabilidades de seguridad, importancia, ventajas e inconvenientes de su uso, así como también las herramientas disponibles para automatizar este tipo de análisis. Se hará una breve introducción al proyecto de seguridad del grupo Stanford SUIF Compiler Group [13] de la Universidad Stanford. En particular se estudia LAPSE [10], una herramienta que realiza el análisis estático para encontrar vulnerabilidades de seguridad en el código Java EE. Finalmente se describirá la herramienta creada para la empresa, de control de Riesgo a nivel teórico, realizado con la herramienta de Microsoft Office: Excel. 12

13 3.5.1 Seguridad en Desarrollos Java Java es considerado un lenguaje seguro. Esto se debe a que el verificador empotrado, ( bytecode verifier ) asegura que no haya manipulación explícita de punteros y de arrays, que las cadenas de caracteres se comprueben automáticamente, que se capturen los intentos de referenciar a un puntero null y que las operaciones aritméticas y de conversión de tipos estén bien definidas e independientes de plataforma. Además en Java existen unos buenos mecanismos de seguridad que controlan el acceso a ficheros individuales, sockets y otros recursos sensibles. Aún así las aplicaciones Java están expuestas a diferentes ataques, por tanto d-core intenta con esto aplicar otro método de auditoría de seguridad como parte del proceso de desarrollo Modelo de seguridad en Java El lenguaje Java ha sido originalmente utilizado por los desarrolladores en el proceso de creación de los applets. Los applets son trozos de código Java que se pueden descargar de forma dinámica desde Internet y ejecutar en el navegador Web. Dado que un código descargado de forma dinámica puede proceder de una fuente desconocida o maliciosa, la seguridad ha sido un aspecto de diseño muy importante en la tecnología Java. Desde sus principios Java ha incluido unos mínimos servicios de seguridad para prevenir el acceso no autorizado del código a los recursos protegidos de un ordenador, como red o ficheros de entrada/salida, modelo de seguridad conocido como sandbox. En este modelo, utilizado en la versión Java 1.0, sólo el código local tenía acceso a todos los recursos del ordenador, mientras que el código descargado de forma remota como applets -, solamente podía acceder a los recursos limitados. En la siguiente versión, Java 1.1, se ha modificado ligeramente el modelo de sandbox permitiendo que el código remoto debidamente autorizado, firmado por una autoridad de certificación de confianza, tuviera los mismos privilegios que el código local. Finalmente Java 1.2 ha introducido un modelo de seguridad basado en políticas configurables en numerosos dominios de protección. En este modelo, tanto el código local como remoto pueden ser obligados a utilizar solamente un dominio específico de recursos de acuerdo a las políticas establecidas en cada momento. Este modelo es mucho más flexible en comparación con modelos anteriores, ya que permite tratar el código local y remoto con las mismas reglas de seguridad. A lo largo de los años, Java ha progresado, implementando medidas para más aspectos de seguridad, teniendo como objetivos principales dar soporte a SSL, S/MIME, PKI, certificados digitales y servicios de autorización y autenticación. Todos estos servicios se basan en un conjunto ampliamente reconocido y soportado por estándares. Actualmente la tecnología Java incluye un extenso conjunto de APIs, herramientas e implementaciones de algoritmos, mecanismos y protocolos de seguridad conocidos. El núcleo de la seguridad en Java está construido por los elementos presentes en la Figura 5. 13

14 Byte Code Verifier: verifica que el bytecode que se carga desde la aplicación Java, pero que procede del código externo a la plataforma Java, se mantenga fiel a la sintaxis del lenguaje Java. Class Loader: es responsable de traducir el bytecode en clases Java que pueden ser manipuladas por el entorno de ejecución Java - JRE. Diferentes Class Loaders pueden emplear diferentes políticas a la hora de decidir si la clase debería ser cargada en el entorno de ejecución o no. Security Manager: es el responsable de decidir si las llamadas invocadas al API de la plataforma Java pueden ser ejecutadas o no. El Class Loader y Java Platform Classes interceptan estas llamadas y las delegan al Security Manager para que tome la decisión. Access Controller: permite una forma más flexible y configurable del control de acceso a los recursos, añadido en la versión Java 2. Permissions: encapsula métodos para designar las limitaciones de acceso y permisos que puedan estar asociados con recursos de valor. Policies: provee el mecanismo para asociar los permisos permissions con los recursos de forma configurable. Protection Domains: encapsula partes que necesitan el mecanismo de control de acceso. Runtime Execution Engine: es el motor que ejecuta finalmente el código. Figura 5: Arquitectura básica de seguridad en Java2 Además J2SE se construye sobre un conjunto adicional de nuevas tecnologías como: Arquitectura Criptográfica de Java - (JCA): provee la infraestructura para llevar a cabo una funcionalidad criptográfica básica con Java. Además incluye una API para el manejo de claves y certificados. Servicio de Autenticación y Autorización Java - (JAAS) JAAS es un framework para proveer los servicios de autenticación y autorización a las aplicaciones Java. Como su nombre indica se divide en dos partes fundamentales: autenticación y autorización. 14

15 Extensión Criptográfica de Java - (JCE) - JCE es un framework para implementación del cifrado, generación de claves y algoritmo MAC para autenticación. Extensión Java para sockets seguros - (JSSE): provee la interfaz para construir aplicaciones Java con soporte del protocolo SSL. SSL (Secure Socket Layer) es un protocolo criptográfico que proporciona conexiones seguras a través de una red de comunicaciones entre cliente y servidor. Estándares para la criptografía de Clave Pública - (PKCS): provee el API para PKCS#11, estándar de criptografía de clave pública para tokens propuesto por RSA. Soporte para Infraestructura de Clave Pública - (PKI): provee API para infraestructura de clave pública, gestión de certificados X509, etc. La mayor ventaja de soporte de seguridad de Java, es la habilidad de proveer el mismo conjunto de servicios de seguridad para entornos heterogéneos de cómputo. Gracias a ello, el conjunto de las características de seguridad del lado del servidor está disponible en diferentes plataformas y hace que el código y servicios de seguridad Java sean muy portables y capaces de comunicarse con aplicaciones y servicios no-java Posibles Ataques y Vulnerabilidades en Java A pesar de que Java provee un modelo de seguridad robusto, existen formas en las que se puede comprometer la seguridad de las aplicaciones creadas con esta tecnología. A continuación se resumirán las principales vulnerabilidades [2]. Los colores de la Figura 6 relacionan la vulnerabilidad con la localización en una aplicación Web. Input Output Aplicación Web To backends Plataforma Aplicación del Servidor Figura 6: Entorno de una aplicación Web donde se puede localizar una vulnerabilidad A1-Entrada no validada A2-Desbordamiento de búfer La información de llamadas Web no es validada antes de ser usada por la aplicación Web. Los agresores pueden usar esta vulnerabilidad para atacar los componentes internos a través de la aplicación Web. Los componentes de aplicaciones Web que no validan adecuadamente las entradas de datos pueden ser derribados y, 15

16 A3-Vulnerabilidades de Inyección A4-Cross Site Scripting (XSS) A5-Revelación de información y gestión incorrecta de errores en algunos casos, usados para tomar el control de un proceso. Estos componentes pueden incluir bibliotecas, rutinas y componentes del servidor de aplicación Web. Las vulnerabilidades de inyección, en particular la inyección SQL, son comunes en aplicaciones Web. La inyección ocurre cuando los datos proporcionados por el usuario son enviados e interpretados como parte de una orden o consulta. Los atacantes interrumpen el intérprete para que ejecute comandos no intencionados proporcionando datos especialmente modificados. Las vulnerabilidades de XSS ocurren cuando una aplicación toma información originada por un usuario y la envía a un navegador Web sin validar primero o codificar el contenido. XSS permite a los atacantes ejecutar secuencias de comandos en el navegador Web de la víctima que pueden secuestrar sesiones de usuario, modificar sitios Web, insertar contenido hostil, etc. 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. Los atacantes pueden usar esta vulnerabilidad para obtener datos delicados o realizar ataques más serios. A6- Control de acceso interrumpido Las restricciones de lo que tienen permitido hacer los usuarios autentificados no se cumple correctamente. Los agresores pueden explotar estas vulnerabilidades para acceder a otras cuentas de usuarios, ver archivos sensibles o usar funciones no autorizadas. A7-Pérdida de autenticación y gestión de sesiones Las credenciales de cuentas y los testigos de sesión (session token) frecuentemente no son protegidos adecuadamente. Los atacantes obtienen contraseñas, claves, o testigos de sesión para suplantar identidades de otros usuarios. 16

17 A8- Almacenamiento criptográfico inseguro A9-Administración de configuración insegura Las aplicaciones Web raramente utilizan adecuadamente funciones criptográficas para proteger datos y credenciales. Los atacantes usan datos débilmente protegidos para llevar a cabo robos de identidad y otros crímenes, tales como fraude con tarjetas de crédito. Tener una configuración de servidor estándar es crítico para asegurar una aplicación Web. Estos servidores tienen muchas opciones de configuración que afectan a la seguridad y no son seguros desde la instalación original del software. A10- Negación de servicio Los agresores pueden consumir los recursos de la aplicación Web hasta el punto de que otros usuarios legítimos no puedan ya acceder o usar la aplicación. Los agresores también pueden dejar a los usuarios fuera de sus cuentas y hasta causar que falle una aplicación entera. A11-Cross Site Request Forgery (CSRF) A12-Ejecución de ficheros malintencionados A13-Referencia insegura y directa a objetos Un ataque CSRF fuerza al navegador validado de una víctima a enviar una petición a una aplicación Web vulnerable, la cual entonces realiza la acción elegida por el atacante a través de la víctima. CSRF puede ser tan poderosa como la aplicación que está siendo atacada. El código vulnerable a la inclusión remota de ficheros (RFI) permite a los atacantes incluir código y datos maliciosos, resultando en ataques devastadores, tales como la obtención de control total del servidor. Una referencia directa a objetos ( direct object reference ) ocurre cuando un programador expone una referencia hacia un objeto interno de la aplicación, tales como un fichero, directorio, registro de base de datos, o una clave en forma de una URL o un parámetro de formulario Web. Un atacante podría manipular este tipo de referencias en la aplicación para acceder a otros objetos sin autorización. 17

18 A14-Comunicaciones inseguras A15-Vulnerabilidades de restricción de acceso a URL Las aplicaciones frecuentemente fallan al cifrar tráfico de red cuando es necesario proteger comunicaciones delicadas. Frecuentemente, una aplicación sólo protege funcionalidades delicadas previniendo la visualización de enlaces o URLs a usuarios no autorizados. Los atacantes utilizan esta debilidad para acceder y llevar a cabo operaciones no autorizadas accediendo a esas URLs directamente Análisis Estático Un análisis estático es un tipo de análisis que se emplea sobre el código de la aplicación sin necesidad de ejecutarla. Se puede realizar tanto sobre el código fuente como sobre el código compilado. El análisis estático en busca de vulnerabilidades de seguridad es uno de los puntos más importantes en la lista de buenas prácticas de software. Los mayores inconvenientes de este tipo de análisis son que puede producir falsos positivos o falsos negativos. Los primeros ocurren cuando el programa contiene errores que el análisis no detecta, mientras que los segundos cuando el análisis detecta errores que el programa no tiene. Además un análisis estático manual puede llegar a ser muy ineficiente. Por tanto es deseable realizar el análisis con ayuda de alguna herramienta que automatice el proceso. Existen varios métodos de análisis estático de aplicaciones con el fin de encontrar vulnerabilidades de seguridad. A continuación se detallan los aspectos más importantes en un analizador estático. Un enfoque es el análisis que tiene en cuenta las reglas léxicas del lenguaje en el que está escrito el programa analizado. Las herramientas que se basan en el análisis léxico, procesan y descomponen a símbolos ( tokens ) el código antes de analizarlo en busca de vulnerabilidades. Este enfoque tiene la desventaja de producir muchos falsos positivos ya que no tiene en cuenta la semántica del código. Otro aspecto a tener en cuenta en un analizador estático es el alcance del análisis. Un análisis local examina una sola función cada vez y no tiene en cuenta las relaciones entre las funciones. Un analizador modular considera una clase o unidad de compilación cada vez, de forma que tiene en cuenta relaciones entre funciones en el mismo modulo, y propiedades aplicables a las clases, pero no las relaciones entre distintos módulos. Un análisis global involucra un programa entero de modo que tiene en cuenta todas las relaciones entre funciones. El alcance del análisis determina también la cantidad de contexto que el analizador considera. Cuanto más contexto, mejor se reducen los falsos positivos, pero también hay más computación que ejecutar. A lo largo de los años se han desarrollado varias herramientas para realizar el análisis estático de seguridad con el fin de encontrar vulnerabilidades de seguridad. Aunque existen herramientas para aplicaciones escritas en diferentes lenguajes, la gran mayoría está destinada a revisar el código C o C++, pero existe una herramienta (entre otras) muy interesante y que para el objetivo de la empresa es muy útil. 18

19 Esta herramienta es un tipo particular de análisis estático para seguridad y es el propuesto por el grupo SUIF: un análisis estático points-to y sensible al contexto (context-sensitive points-to). Es un análisis escalable a aplicaciones de un tamaño elevado y su enfoque puede ser utilizado para el análisis de otros lenguajes orientados a objetos como por ejemplo C#. Este análisis se hace sobre el bytecode de la aplicación, haciendo imprescindible por tanto la disponibilidad de al menos el código fuente de la aplicación a analizar. Las vulnerabilidades analizadas son las causadas por las entradas de usuario que no se comprueban de forma adecuada. Dado que la investigación se basa en lenguaje Java, se ha estudiado esta herramienta y una vez obtenida toda la documentación necesaria y que posteriormente sea aceptada por d- Core, se integró al proyecto. Antes de comenzar a detallar LAPSE, se hará una breve descripción de otros analizadores estáticos Otros Analizadores Estáticos Existen varias herramientas open source, para realizar auditoria de seguridad sobre el código fuente de la aplicación, mediante análisis estático. Sin embargo, la mayoría de estas herramientas está destinada a auditar aplicaciones escritas en C o C++. LAPSE, según sus desarrolladores, es la primera herramienta de análisis estático en busca de vulnerabilidades de seguridad para Java. A continuación se describen varios ejemplos de herramientas existentes. Las cuatro primeras (ITS4, Pscan, RATS y FlawFinder) utilizan solamente el análisis léxico para el escaneo del código. Este tipo de análisis provoca muchos falsos positivos. Los cuatro últimos analizadores descritos (BOON, CQual, MOPS y Splint) tienen en cuenta también la semántica del lenguaje que analizan, gracias a lo cual consiguen resultados más precisos. ITS4 La primera herramienta para detectar los problemas de seguridad mediante el análisis de código fuente fue ITS4, desarrollada a principios de 2000 por Cigital. ITS4 es una herramienta muy simple que escanea el código C y C++ para encontrar potenciales vulnerabilidades de seguridad. Es una herramienta que funciona por línea de comandos en plataformas Windows y Linux. ITS4 escanea el código en busca de llamadas a funciones que pueden ser peligrosas. La herramienta utiliza un conjunto de reglas simples en las que se basa para encontrar las posibles vulnerabilidades. Por ejemplo, el uso de la función strcpy() debería ser evitado. Para algunas de las llamadas ITS4 intenta analizar qué nivel de riesgo tienen. Para cada caso la herramienta produce un informe sobre el problema encontrado, con una descripción corta y sugerencias de cómo puede arreglarse el código. 19

20 Pscan Pscan es un escáner para detectar los problemas de seguridad en código C. En particular pscan detecta los problemas de formato de cadenas que pueden provocar ataques de desbordamiento de buffer. Pscan detecta como vulnerabilidad los métodos de la librería printf que toman las cadenas como parámetros y ninguno de los argumentos es el especificador de conversión (eg. %s, %c, etc.). Este tipo de expresiones podría provocar un ataque de desbordamiento de buffer, ya que el usuario podría introducir su propio especificador de conversión dentro de la variable pasada como argumento. Un método de la librería printf, si no se le pasa explícitamente a un especificador de tipos, tratará como tal cualquier cadena de tipo %c que encuentre dentro de la variable que toma como argumento. Esta herramienta es muy limitada en comparación con otras diseñadas para el análisis estático, que solamente detecta un tipo de errores. RATS - Rough Auditing Tool for Security RATS, desarrollado por los ingenieros de Secure Software, que actualmente pertenece a Fortify Software, es una herramienta para escanear el código fuente de las aplicaciones escritas en C, C++, Perl, PHP y Python con el fin de encontrar errores de seguridad como desbordamiento de buffer o condiciones de carrera TOCTOU (Time Of Check to Time Of Use). RATS utiliza una base de datos para encontrar sentencias del código que pueden ser una vulnerabilidad potencial. El usuario puede decidir qué base de datos utilizar en el escaneo y qué nivel de riesgo asumir. Por cada problema potencial encontrado, RATS proporciona la descripción del mismo y sugiere una solución al respecto. Además indica el grado de severidad del problema encontrado para facilitarle al auditor la asignación de prioridades. RATS ejecuta un análisis básico para descartar condiciones que no causan problemas de seguridad. El análisis con RATS no es completo ya que no encuentra todos los errores existentes y puede destacar como errores casos que no lo son. FlawFinder FlawFinder es una herramienta, escrita en Phyton, que analiza el código fuente de los programas escritos en C o C++ para encontrar posibles vulnerabilidades de seguridad y ordena los problemas encontrados según el nivel del riesgo. Como en el caso de RATS el análisis no es completo, ya que pueden producirse falsos positivos, como también pueden existir vulnerabilidades no detectadas por FlawFinder. FlawFinder fue desarrollado casi simultáneamente con RATS y las dos herramientas son muy parecidas. FlawFinder, como RATS, funciona utilizando una base de datos empotrada con funciones C/C++ que pueden provocar problemas de seguridad conocidos, tales como desbordamiento de buffer, condiciones de carrera, o problemas con el formato de cadenas. El escaneo consiste en analizar el código fuente de la aplicación en busca de estas funciones. BOON Buffer Overun detection es una herramienta que sirve para encontrar vulnerabilidades de desbordamiento de buffer en el código C. Boon aplica un análisis de rango del integer para determinar si un programa C puede indexar algún array fuera de sus límites. Para ello modela cada buffer como un par de rangos del integer, el primer rango sirve para saber el número de bytes asignado, y el otro rango indica el número de bytes en uso. El análisis 20

21 verifica por cada buffer si su tamaño de asignación es al menos tan grande como su máxima longitud. BOON es capaz de encontrar muchos errores. Aun así no es muy preciso ya que ignora el orden de las sentencias del código, y es incapaz de modelar dependencias entre funciones o referencias de punteros. MOPS MOPS, MOdelchecking Programs for Security properties, utiliza un enfoque formal de chequeo del modelo para buscar violaciones de las propiedades de seguridad. MOPS construye un modelo formal del programa y de la propiedad de seguridad y posteriormente analiza este modelo. Los desarrolladores pueden modelar sus propias propiedades de seguridad y algunos han utilizado la herramienta para detectar errores de gestión de privilegios, la construcción incorrecta de chroot jails, condiciones de carrera en acceso a ficheros o esquemas incorrectos de ficheros temporales. CQual Cqual es una herramienta de análisis basada en tipos, que sirve para detectar las vulnerabilidades de formato de cadenas en C como también errores de confianza entre espacio de usuario y espacio del kernel. CQual extiende el sistema de tipos de C, mediante unos calificadores. Se basa en modo taint mode de Perl, el cual trata y utiliza calificadores de tipo para realizar análisis taint. El programador debe anotar varias variables como tainted o untainted y luego utilizar las reglas de inferencia para propagar calificadores. De esta forma no tiene que añadir muchas anotaciones, ya que con unas pocas se infieren automáticamente a todo el programa. Una vez propagados los calificadores, el sistema puede detectar vulnerabilidades de cadenas mediante chequeo de tipos. Para analizar el programa, CQual recorre el árbol AST y genera una serie de restricciones que capturan relaciones entre calificadores. La solución a estas restricciones da una asignación válida de los calificadores de tipo a variables en el programa. Si la restricción no tiene solución, ocurre una inconsistencia de calificadores de tipo, la cual indica una vulnerabilidad potencial. Splint Splint es una herramienta de análisis estático ligero lightweight para código C. Extiende el concepto de lint, herramientas de análisis estático de código, al mundo de seguridad. Splint encuentra vulnerabilidades típicas de seguridad de lenguaje C, como desbordamiento del buffer, formato de cadenas, etc. Aparte de las verificaciones empotradas, Splint proporciona un mecanismo para definir nuevos chequeos y anotaciones para detectar nuevas vulnerabilidades. Splint encuentra vulnerabilidades potenciales comprobando si el código fuente es consistente con propiedades emergentes de anotaciones. Añadiendo anotaciones, los desarrolladores pueden permitir a la herramienta encontrar diversas vulnerabilidades, tales como violaciones de abstracción, modificaciones de variables globales sin anunciar o posibles usos sin inicialización. 21

22 LAPSE LAPSE (Lightweight Analysis for Program Security in Eclipse) es una herramienta para realizar la auditoría de seguridad en las aplicaciones Java. Fue creado por Benjamin Livshits, como parte del proyecto Griffin Software Security Project de la Universidad de Stanford. [11] LAPSE analiza el código J2EE para encontrar las vulnerabilidades más comunes en aplicaciones Web. La herramienta tiene como objetivo encontrar las vulnerabilidades de seguridad en las aplicaciones Web, causadas por validación inadecuada o nula de las entradas del usuario. Este tipo de vulnerabilidades es ampliamente reconocido como el más frecuente en las aplicaciones Web. En particular, dos de los ataques de este tipo, el ataque de XSS ( Cross Site Scripting ) y la Inyección SQL, son los más comunes. La idea principal de LAPSE, es ayudar al programador a desinfectar las entradas venenosas tainted input (entradas envenenadas). Tipos de Vulnerabilidades de Seguridad Encontradas por LAPSE Los ataques en las aplicaciones Web causados por entradas de usuario inadecuadamente validadas se pueden dividir en dos grupos. El primer grupo consta de los ataques que inyectan datos maliciosos en las aplicaciones Web mientras que el segundo grupo son los ataques que manipulan las aplicaciones Web. La combinación de un ataque del primer grupo con su correspondiente del segundo es una vulnerabilidad de seguridad. Ataques de Inyección de Datos Maliciosos en las Aplicaciones Web Las aplicaciones Web pueden obtener la información del usuario de diferentes maneras, tales como parámetros de formularios HTML, cabeceras HTTP, valores de cookies, etc. Por tanto es difícil proteger las aplicaciones ante entradas de datos maliciosos. La protección en la parte del cliente no es suficiente ya que se puede manipular fácilmente. Por tanto es necesario proporcionar una protección contra este tipo de ataques en la parte del servidor. A continuación se detallan los ataques particulares existentes: Alteración de parámetros: este ataque se basa en introducir valores manipulados de forma maliciosa en los campos de texto o formularios HTML. Estos valores son enviados dentro de la petición HTTP. Manipulación de URL: este ataque tiene lugar cuando los parámetros de los formularios HTML aparecen como parte de la URL a la que se accede después de enviar el formulario con el método HTTP GET. El atacante puede editar la URL de forma directa, añadir los datos trampa en ella y luego acceder a ella de forma maliciosa. Manipulación de campos ocultos: los campos ocultos se utilizan en HTTP para mantener el estado entre peticiones. Aunque estos campos no son visibles para el usuario final, se pueden modificar desde el código fuente de la página. Alteración de cabeceras HTTP: las cabeceras HTTP normalmente no son visibles para el usuario final. Sin embargo algunas aplicaciones sí que procesan estas cabeceras y algunos usuarios podrían pasar un código malicioso a través de ellas a la aplicación. 22

23 Envenenamiento de Cookies: una cookie es un pequeño fichero guardado en el ordenador del usuario final y accesible por la aplicación Web. Sirve para guardar la información con el login y contraseña u otros identificadores del usuario. Esta información se suele guardar en el ordenador después del primer acceso del usuario a la aplicación Web. El envenenamiento de cookies es una variación de la alteración de cabeceras HTTP, ya que se puede pasar el código maligno guardándolo a través de valores en cookies. Fuentes No Web: los datos malignos pueden ser introducidos a la aplicación no solamente a través de las peticiones Web. Aunque es menos común, puede pasar que los datos sean introducidos por línea de comandos, o como argumentos del método main(). Ataques de Manipulación de Aplicaciones Web con Datos Maliciosos Una vez los datos maliciosos se han insertado en la aplicación, el atacante puede manipularlos mediante diversas técnicas. A continuación se enumeran los ataques conocidos: Inyección SQL: sucede cuando se inserta o "inyecta" un código SQL "invasor" dentro de otro código SQL para alterar su funcionamiento normal, y hacer que se ejecute maliciosamente el código "invasor" en la base de datos. Cross-site Scripting: las vulnerabilidades de XSS originalmente abarcaban cualquier ataque que permitiera ejecutar código de "scripting", como VBScript o JavaScript, en el contexto de otro sitio web (y recientemente esto se podría clasificar más correctamente como "distintos orígenes"). HTTP response-splitting: este ataque se basa en juntar dos respuestas HTTP para una sola petición, mediante el uso de saltos de línea inesperados. La segunda respuesta HTTP puede ser juntada de forma errónea con la siguiente petición, y controlándola el atacante puede generar varios ataques, tales como envenenar las páginas web del servidor proxy. Path Traversal: La técnica de ataque Path Traversal fuerza el acceso a ficheros, directorios y comandos que potencialmente residen fuera del directorio document root del servidor web. Es más complicado de prevenir de lo que puede parecer. Una estrategia de filtrar los caracteres que puedan suponer una amenaza, es probable que falle. Hay muchos más factores implicados que pueden determinar el funcionamiento de un ataque directory traversal. Sin embargo, si la aplicación no valida la legitimidad de los parámetros, es bastante probable que los atacantes tengan muchas probabilidades de explotar esta funcionalidad para propósitos maliciosos. Inyección de comandos: este ataque ocurre cuando se pasan los comandos de consola a las aplicaciones para su ejecución. Este ataque es menos común en las aplicaciones Web, especialmente las escritas en Java. Implementación de Lapse LAPSE se distribuye como un plug-in de Eclipse, bajo licencia GNU General Public License (GPL), siendo por tanto una aplicación Open Source. 23

24 Para realizar este PFC, se ha utilizado la versión de LAPSE para estudiar su funcionamiento. A continuación se describe cómo está implementado el plug-in. La versión de Eclipse utilizada es eclipse 3.2, siendo ésta la única compatible con LAPSE Eclipse [18], como definen sus fundadores, es una comunidad de código abierto, cuyos proyectos se centran en construir una plataforma de desarrollo abierta, compuesta de unos frameworks extensibles, herramientas y runtimes para construcción, despliegue gestión de software durante su ciclo de vida. Además, LAPSE utiliza APIs Eclipse JDT para manipular el código fuente que debe analizar. El JDT ( Java Development Tool ) provee una API para acceder y manipular el código fuente de Java. Permite acceder, leer y modificar proyectos existentes en el workspace de Eclipse, así como también crear proyectos nuevos. JDT permite además lanzar programas Java. Al código fuente Java se puede acceder en JDT mediante Java Model o Abstract Syntaxt Tree (AST). LAPSE utiliza las dos modalidades para tratar el código. Dado que ECLIPSE es un entorno de desarrollo integrado (IDE), permite mostrar, mediante vistas específicas, en qué parte del programa se da la vulnerabilidad de seguridad. LAPSE define 3 vistas diferentes: Vulnerability Source permite al usuario navegar libremente entre fuentes de datos de usuario. Vulnerability Sink - permite al usuario navegar libremente entre llamadas que manejan cadenas que serán ejecutadas de forma maliciosa, por ejemplo sobre bases de datos en el caso de SQL Injection. Provenance Tracker permite encontrar orígenes de un valor particular en el código fuente siguiendo el flujo de datos hacía atrás. La mayor funcionalidad está implementada en la vista Provenance Tracker ya que en ella se muestra al usuario el camino de la propagación desde objeto sink al objeto source. Cada una de estas vistas tiene su propia implementación, y además LAPSE utiliza otros plug-ins y librerías de Eclipse que facilitan la tarea de análisis del código. LAPSE implementa el proceso de registro de errores, de forma que todos los avisos sobre los comportamientos no típicos de la aplicación se guardan en un fichero.log en la carpeta.metadata ubicada en el workspace del proyecto. En la Figura 7 se muestra el diagrama de clases UML del LAPSE. Este diagrama tiene como objetivo mostrar el diseño general de la herramienta con sus clases y métodos más importantes. 24

25 Figura 7: Diagrama de clases UML de LAPSE Descripción de las tres vistas que implementa LAPSE: 1. SourceView En esta vista se muestran todas las posibles fuentes sources de datos de usuario. Para el análisis en busca de objetos de tipo source LAPSE utiliza un fichero sources.xml. En este fichero se describen todos los elementos source que pueden ser fuente de una posible vulnerabilidad. El fichero tiene la estructura especificada en el DTD descrito en el listado 1 (Fichero sources.dtd ) siguiente: <! ELEMENT SOURCES (source*)> <! ELEMENT SOURCE (category)> <! ELEMENT CATEGORY #CDATA> <! ATTLIST SOURCE ID CDATA #REQUIRED> Listado 1: Fichero Sources.dtd El atributo ID del elemento SOURCE expresa el nombre completo del método cuya invocación puede ser una posible fuente de la vulnerabilidad, mientras que el elemento CATEGORY expresa el tipo de la vulnerabilidad. Una vez leído el listado de objetos source, se recorre el código en busca de líneas donde se invocan estos métodos. Para buscar las invocaciones en el código, de los métodos definidos en el fichero sources.xml, se hace uso del mecanismo de búsqueda SearchEngine de Java. 25

26 En LAPSE el proceso de búsqueda de los objetos source de vulnerabilidades es el siguiente: 1. Se lee la entrada <source> del fichero source.xml. 2. Se encapsula la entrada leída en la clase SourceDescriptor, donde aparte del nombre completo del método (incluyendo el paquete en el que está definido), se guarda la información sobre la categoría de la vulnerabilidad que puede ser provocada por la invocación del método. 3. Se busca a través del proceso de búsqueda de Java, todas las referencias (invocaciones) del método source actual. 4. Los pasos de 1) a 3) se repiten por cada entrada del fichero sources.xml y por cada proyecto abierto en el workspace actual del Eclipse. 5. Finalmente se recupera el listado con todos los resultados obtenidos en el proceso de búsqueda. Por cada elemento del listado se comprueba si su nodo es una invocación de método, y si es así se añade el resultado en la vista SourceView de usuario. Menú principal de la vista Source View : Figura 8: Source View Implementa 5 acciones. Dos se corresponden con el menú contextual e implementan la búsqueda de objetos source y la realización de una copia de la selección al portapapeles. Las otras dos se corresponden a las opciones del menú, como filtrar los resultados para ver los objetos source sin código fuente (por ejemplo los que aparecen en librerías). La última acción corresponde a un doble clic sobre una fila, y esto abre el fichero correspondiente, en el editor de eclipse. LAPSE utiliza también el fichero safes.xml, donde se especifican todos los métodos que se consideren seguros. Por ejemplo, si se sabe que para una vulnerabilidad particular un método siempre es seguro, aunque aparezca en el fichero sources.xml, se puede incluir en el fichero safes.xml. 2. SinkView La vista SinkView implementa la búsqueda y la presentación al usuario de llamadas que manejan cadenas que pueden ser ejecutadas de forma maliciosa. Todos los métodos de tipo sink, se definen en el fichero sinks.xml. Este fichero tiene una estructura definida con el dtd en el siguiente listado 2 "sinks.dtd": 26

27 <! ELEMENT SINKS (sink*)> <! ELEMENT SINK (paramcount, vulnparam, category)> <! ELEMENT PARAMCOUNT #CDATA> <! ELEMENT VULNPARAM #CDATA> <! ELEMENT CATEGORY #CDATA> <! ATTLIST SINK ID CDATA #REQUIRED> Listado 2: Fichero sinks.dtd El atributo ID del elemento SINK expresa el nombre completo del método cuya invocación sobre un objeto sin validar puede ser un posible ataque. El elemento PARAMCOUNT indica el número de parámetros que posee el método y el elemento VULNPARAM especifica el número de parámetro vulnerable, empezando por 0. El elemento category expresa el tipo de la vulnerabilidad provocada por este método sink, por ejemplo: Cross Site Scripting. Una vez leído el listado de objetos sink, se recorre el código en busca de líneas donde se invocan estos métodos. Para buscar las invocaciones en el código de los métodos definidos en el fichero sink.xml, se hace uso, como en el caso de sources.xml del mecanismo de búsqueda SearchEngine de Java. En LAPSE el proceso de búsqueda de los objetos sink de vulnerabilidades es el siguiente: 1. Se lee la entrada <sink> del fichero sink.xml. 2. Se encapsula la entrada leída en la clase SinkDescriptor, donde aparte del nombre completo del método (incluyendo el paquete en el que está definido), se guarda la información sobre el número de parámetros que posee el método, el número de parámetro vulnerable y la categoría de la vulnerabilidad de seguridad que puede provocar la invocación del método. 3. Se buscan todas las referencias (invocaciones) del método sink actual. 4. Se comprueba si el parámetro de llamada es o apunta a una cadena constante, para poder diferenciar las invocaciones peligrosas de las que no lo son. 5. Los pasos 1) a 3) se repiten por cada entrada del fichero sinks.xml y por cada proyecto abierto en el workspace actual del Eclipse. 6. Se recupera el listado con todos los resultados obtenidos en el proceso de búsqueda. Por cada elemento del listado se comprueba si se trata de una invocación de método o de creación de la instancia de clase, respectivamente, si es así se comprueba el argumento definido como vulnerable para averiguar si la invocación es segura o no. Todos los argumentos que no sean una cadena constante se tratan como inseguros tainted. Esto incluye referencias a otro objeto, concatenación de cadenas con alguna de ellas no constante o invocación de método. 7. Finalmente se añaden los resultados en la vista SinkView de usuario. 27

28 Menú principal de la vista Sink View : Figura 9: Sink View Una de las opciones de este menú permite hacer la propagación hacía atrás para encontrar el camino a la fuente source de los datos utilizados en el método sink. Esto es el proceso clave de LAPSE. Si de una sentencia de tipo sink, se puede llegar a un objeto de tipo source, (mediante propagación hacia atrás, a través de declaraciones de variables, invocaciones de métodos, asignaciones, etc.) esto significa que el programa es vulnerable al ataque de la categoría especificada. Cuando el usuario escoge la opción de propagación hacía atrás desde un resultado sink elegido, se muestra automáticamente la vista Provenance Tracker, en la que se enseña el camino buscado. Las otras opciones del menú contextual son parecidas a las vistas en el mismo menú de Source View : una sirve para buscar todos los objetos de tipo sink y la otra para copiar la selección al portapapeles. La acción de toggle safe status, permite cambiar el estado de un objeto sink de seguro a inseguro y al revés, lo cual es útil cuando el usuario quiere reflejar que un objeto sink es inseguro o seguro a pesar de que LAPSE no lo haya detectado como tal. La acción get sink statistics muestra unas estadísticas del proceso de búsqueda de objetos sink. Se puede apreciar el número total de los objetos sink encontrados, el número total de los inseguros y de los inseguros de cada categoría definida. 3. Provenenance Tracker La vista Provenance Tracker implementa el proceso de propagación de los datos manejados en métodos identificados como sink al origen de los mismos. Si el origen coincide con alguna invocación del tipo source, el programa es vulnerable al ataque definido. El elemento en el cual se empieza la propagación se puede elegir de dos formas: escogiendo un método sink en la vista sink view y eligiendo en el menú contextual la opción Perform Backward Propagation from the Sink o bien seleccionado alguna expresión en uno de los ficheros fuente abiertos en el editor del workspace. La vista Provenance Tracker permite al usuario personalizar algunas de sus propiedades. Por un lado se puede establecer el límite de propagación entre expresiones o se puede optar por no poner ningún límite (este límite es 10 por defecto). 28