Soluciones. Plataforma Avanza Local Soluciones AL SIGM Buenas prácticas de calidad en el desarrollo de aplicaciones SEGURIDAD

Transcripción

1 Soluciones Buenas prácticas de calidad en el desarrollo de aplicaciones Plataforma Avanza Local Soluciones AL SIGM Buenas prácticas de calidad en el desarrollo de aplicaciones SEGURIDAD Página 0

2 Índice: 1. Introducción 2. Principios del desarrollo seguro 3. Recomendaciones 3.1 Acceso a base de datos Inyección SQL Control de acceso 3.2 Acceso al sistema de ficheros Manipulación de rutas Inyección de comandos Uso indebido: subida de archivos 3.3 Gestión de logs Falsificación de log Usos indebidos 3.4 Configuración Contraseñas en ficheros de configuración Esquema XML débil 3.5 Generación de contenido web Cross-Site Scripting (XSS) Manipulación de cabeceras Cross-Site Request Forgery 3.6 Criptografía Encriptación débil 3.7 Control de acceso Fijación de sesión 3.8 Diseño Condición de carrera: Variable miembro Singleton Almacenar objetos no serializables en sesión 3.9 Gestión de recursos Recurso no liberado Denegación de servicio 3.10 Revelación de información Violación de privacidad Fuga de información del sistema Contraseñas escritas directamente en el código 4. Verificación 5. Valoración de la seguridad de las aplicaciones 6. ENS (Esquema Nacional de Seguridad) Página 1

3 1. INTRODUCCION Esta guía se encuentra dividida en tres apartados principales. La información en cada uno de estos apartados se estructura de la siguiente manera: En primer lugar, se describen los principios en los que debe basarse el desarrollo de software para mejorar la calidad de la aplicación en cada una de las categorías. Como segundo punto se detallan recomendaciones a nivel de codificación, orientadas principalmente a usuarios con perfil de desarrollador dentro de la comunidad. A continuación, como tercer punto, se especifican pautas que deben llevarse a cabo para verificar si las recomendaciones de codificación han sido implementadas y, por tanto, la aplicación no contiene problemas de seguridad. En este caso, las recomendaciones están orientadas a aquellos usuarios que poseen un rol de auditor dentro de la comunidad. Por último, el gestor de la comunidad será el encargado de valorar los resultados obtenidos en el punto anterior con el fin de determinar el grado de cumplimiento de las recomendaciones establecidas en el ámbito de la seguridad, adoptando acciones correctivas siempre que sea necesario. Seguridad Como se ha comentado anteriormente, la seguridad de la información se basa en los tres siguientes pilares principales: Confidencialidad. Sólo se debe permitir el acceso a los datos a los cuales el usuario está autorizado. Integridad. Se debe asegurar que los datos no son manipulados por usuarios no autorizados. Disponibilidad. Los datos deben estar disponibles de manera permanente para los usuarios autorizados. Para garantizar el cumplimiento de estos tres fundamentos, durante el desarrollo de las aplicaciones deben implementarse distintos controles de seguridad. En general, pueden encajarse en los siguientes grupos en función del objeto para el cual se construyan: Controles de prevención de accesos no autorizados. Controles sobre las entradas de datos en la aplicación, para evitar que ciertos datos provoquen que la aplicación no se comporte de la manera deseada. Controles para asegurar el funcionamiento correcto de la aplicación cuando está siendo directamente atacada. Controles de gestión de la propia aplicación para monitorizar la actividad de la aplicación y configurar su comportamiento. Página 2

4 Piensa como el atacante Los desarrolladores involucrados en la implementación de estos controles de seguridad deben ponerse en la piel de un usuario atacante, valorando en cada una de las funcionalidades que esté implementando los siguientes puntos: el proceso que envuelve a la funcionalidad es seguro? de qué manera podría abusar de esa funcionalidad? es necesario que la funcionalidad esté activa por defecto? Si es así, qué opciones minimizan el riesgo de uso de la misma? Toda entrada es maliciosa Además, el desarrollador debe tener en cuenta en todo momento durante el desarrollo que la aplicación debe considerar que toda entrada es potencialmente maliciosa y reaccionar aplicando las medidas necesarias que aseguren que un atacante no pueda utilizar estas entradas como medio para comprometer la aplicación. No existe el software libre de errores El software siempre tendrá errores y, por extensión, vulnerabilidades de seguridad. Por lo tanto, un objetivo práctico en el ciclo de vida de desarrollo de software seguro debería ser reducir al máximo (no necesariamente eliminar), el número de vulnerabilidades introducidas y la severidad de aquellas que no hayan sido eliminadas. Una sola vulnerabilidad SÍ es suficiente La explotación de una única vulnerabilidad en una aplicación web es suficiente para interrumpir de manera significativa el negocio, provocar pérdida de datos, dañar la confianza del cliente, etc. Por ello, cuanto antes sean identificadas y corregidas las vulnerabilidades, menor será la oportunidad para un atacante de explotarlas maliciosamente. Página 3

5 2. PRINCIPIOS DE DESARROLLO SEGURO Independientemente del lenguaje y la arquitectura utilizados, el desarrollo de la aplicación y de los controles de seguridad necesarios deben llevarse a cabo teniendo en cuenta una serie de principios de seguridad que traten de reducir la probabilidad de la realización de amenazas y el impacto de éstas en el caso de que se hayan producido ya. Aunque estos principios pueden servir como pautas generales, para que sean realmente útiles, deben ser evaluados, interpretados y aplicados para abordar cada problema específico. La consideración de cada uno de ellos puede derivar en la identificación de requisitos de seguridad, la toma de decisiones relativas a la arquitectura y la implementación e identificación de posibles debilidades en el sistema. Minimizar la superficie de ataque Cada funcionalidad que se incorpora a una aplicación añade cierto riesgo al conjunto. Uno de los principios de la programación segura consiste en disminuir el riesgo reduciendo la superficie de ataque. Por ejemplo, si una aplicación implementa un módulo de ayuda con una funcionalidad de búsqueda, dicha funcionalidad puede ser vulnerable a inyección SQL. Si la ayuda está limitada a usuarios autorizados, la posibilidad de ataque se reduce. Si además la funcionalidad de búsqueda utiliza rutinas de validación de los datos de entrada, la posibilidad de inyección SQL disminuye drásticamente. Sin embargo, si la ayuda se rediseña y se elimina la posibilidad de búsqueda (proporcionando como alternativa una mejor interfaz de usuario), esto prácticamente elimina la superficie de ataque del módulo de ayuda, incluso si la ayuda fuese accesible desde Internet. Seguridad por defecto Cuando una aplicación se despliega en su entorno de producción, utiliza una serie de opciones de configuración que se establecen por defecto. Estas opciones por defecto deben ser tales que la aplicación sea segura. Es responsabilidad del usuario modificar dichas opciones aún a costa de disminuir la seguridad. Por ejemplo, por defecto una aplicación debería tener habilitada la expiración de contraseñas y una política de complejidad de claves adecuada. Una vez desplegada, los usuarios podrían deshabilitar estas opciones o relajar las restricciones aún a costa de aumentar el riesgo, pero siempre bajo su responsabilidad. Ejecución con los mínimos privilegios El principio de mínimos privilegios establece que las cuentas deben tener el menor nivel de privilegios posible para realizar las tareas de negocio. Este nivel de privilegios abarca tanto permisos de usuarios como permisos sobre recursos como CPU, memoria, red, sistema de ficheros, etc. Por ejemplo, si una aplicación sólo requiere acceso a la red, permisos de lectura sobre una tabla de la base de datos y la posibilidad de escribir en un fichero de log, estos Página 4

6 deben ser los únicos permisos que debe tener la cuenta bajo la que se ejecute la aplicación. Bajo ningún concepto la aplicación debe tener permisos administrativos. Defensa en profundidad El principio de defensa en profundidad sugiere que donde un único control de seguridad podría ser asumible, sería mejor utilizar varios controles que afronten el riesgo desde distintos puntos de vista. Los controles de seguridad, cuando se utilizan con el enfoque de defensa en profundidad, hacen que vulnerabilidades que pueden ser muy graves, sean tremendamente difíciles de explotar. Por ejemplo, siguiendo este principio, una aplicación implementaría distintas medidas en varias capas para prevenir inyecciones SQL: rutinas de validación de datos para comprobar las entradas del usuario, consultas parametrizadas a la hora de ejecutar las sentencias SQL y establecimiento adecuado de permisos a nivel de tablas y procedimientos almacenados en la base de datos. Fallar de forma segura En muchas ocasiones se producen errores cuando las aplicaciones realizan una transacción. El estado en que la aplicación queda cuando se produce dicho error, determina si la aplicación es segura o no. Supongamos el siguiente fragmento de código. isadmin = true; try { codewhichmayfail(); isadmin = isuserinrole( Administrator ); catch (Exception ex) { log.write(ex.tostring()); Si los métodos codewhichmayfail() o isuserinrole() fallan o lanzan una excepción, el usuario queda como administrador (isadmin=true), lo cual, obviamente, es un problema de seguridad. La aplicación debe garantizar, en este ejemplo, que en caso de error el valor de isadmin sea false. Detección de intrusos La detección de intrusiones requiere la existencia de tres elementos: Capacidad para incluir en el log eventos relevantes de seguridad. Procedimientos que aseguren que los logs son monitorizados con regularidad. Procedimientos para responder adecuadamente a una intrusión una vez ha sido detectada. Toda la información de seguridad relevante debe ser registrada en un log. Es posible que un problema que no pudo ser detectado en tiempo de ejecución, pueda serlo gracias a la revisión de los logs. Para ello, es fundamental que se registre suficiente información para ayudar a localizar al atacante y que se proporcione un método para Página 5

7 gestionar la información registrada. Si al analizar los eventos registrados no se puede determinar cuáles de ellos son procesables, se pierde el valor que posee el registro de dichos eventos. No se debe confiar en otras tecnologías para detectar intrusiones. El código de cada aplicación es el único componente del sistema que tiene suficiente información para detectar ataques de manera fiable. Sólo la propia aplicación conoce qué parámetros son válidos, qué acciones están permitidas para el usuario, etc. Por ello, debe construirse dentro de la misma. La importancia de la detección de intrusiones reside en que, sin ella, se proporciona al atacante tiempo ilimitado para perfeccionar un ataque. Si la detección de intrusiones fuese perfecta, el atacante tendría un único intento antes de ser detectado y de que pueda lanzar otros ataques. No confiar en los servicios Muchas organizaciones utilizan servicios proporcionados por terceras partes para realizar determinados procesos de negocio. Sin embargo, estas terceras partes pueden tener criterios y políticas de seguridad muy distintas a las de la organización que usa el servicio. Por lo tanto, todos los sistemas y servicios externos deben ser tratados como no confiables. Por ejemplo, una aplicación de banca puede utilizar un servicio externo que ofrece información sobre cotización de acciones. Pues bien, la aplicación de banca debería validar todos los datos que le llegan de este servicio externo para comprobar que son seguros para ser mostrados en una página web, que tienen el tipo y rango correctos, etc. Evitar la seguridad por ocultación La seguridad por ocultación es un mecanismo de seguridad débil y generalmente falla cuando es el único control existente. La seguridad de un sistema nunca debe recaer en la cultación de secretos. Por ejemplo, la seguridad de una aplicación no puede depender de mantener en Página 6

8 secreto el código fuente. Un ejemplo podría ser el sistema operativo Linux; su código fuente está disponible, sin embargo, cuando está correctamente configurado, es un sistema seguro. Mantener la simplicidad Cuando el código fuente es muy complejo es más complicado hacerlo seguro. Es mejor mantenerlo simple. Hay que tener en cuenta que cuando se desarrollan nuevas versiones o se solucionan defectos, los programadores que intentan hacer segura la aplicación pueden no ser los mismos que desarrollaron el código inicialmente. Cuantas más líneas de código hay, más probabilidades de introducir vulnerabilidades. Solucionar correctamente los problemas de seguridad Una vez que se ha detectado un problema de seguridad, es fundamental desarrollar pruebas para reproducirlo y detectar la causa raíz. Una vez que se desarrolla una solución válida es clave garantizar que no se introducen problemas de regresión. Por ejemplo, un usuario descubre que puede ver datos de otro usuario modificando un valor en una cookie. Pero debido a que el mecanismo de gestión de cookies es compartido por todas las aplicaciones, un cambio en el código de este control afecta no sólo a la aplicación en la que se detectó el problema, sino a todas. Por lo tanto, la solución debe ser probada en todas las aplicaciones. Página 7

9 3. Recomendaciones Como se ha tratado anteriormente, durante el desarrollo de una aplicación deben implementarse controles que garanticen la seguridad de la misma. Los errores de programación que se cometen durante esta implementación pueden desembocar en vulnerabilidades de seguridad en las aplicaciones. A continuación se describen algunos de estos problemas o vulnerabilidades de seguridad, basados en las siguientes listas de referencia, en las que se incluyen los errores más críticos y extendidos que pueden conducir a vulnerabilidades serias en las aplicaciones, generalmente fáciles de encontrar y explotar: 2010 CWE/SANS Top 25 Most Dangerous Programming Errors OWASP Top Ten Project El grado de explotación de muchas de estas vulnerabilidades es mayor de lo que un desarrollador pueda pensar a priori. En el gráfico siguiente, basado en el estudio realizado por WhiteHat Security en el año 2010, puede verse la probabilidad de aparición de algunas de estas vulnerabilidades: Como puede verse, el 64% de los sitios web del estudio poseían al menos una vulnerabilidad de fuga de información del sistema y de Cross-Site Scripting. Además, en el estudio se destaca el crecimiento respecto a años anteriores del porcentaje de vulnerabilidades de Cross-Site Request Forgery. Por último, el estudio subraya que, a pesar de que se resolvieron gran cantidad de vulnerabilidades de tipo SQL Injection, en un 14% de los sitios web se detectó todavía este tipo de problema. Página 8

10 En los apartados que se encuentran a continuación se explica cómo puede ser explotado cada tipo de vulnerabilidad, proporcionando ejemplos y recomendaciones en lenguaje Java para prevenir posibles ataques que puedan aprovechar la vulnerabilidad en cuestión. 3.1 Acceso a bases de datos 3.1. Inyección SQL Descripción Construir una sentencia SQL dinámica utilizando para ello la entrada proporcionada por un usuario podría permitir a un atacante modificar el significado de la sentencia o incluso ejecutar comandos SQL arbitrarios. Los errores de inyección SQL se presentan cuando se cumplen las siguientes condiciones: El programa recibe datos que proceden de una fuente no confiable. Dichos datos son utilizados para construir dinámicamente una sentencia SQL. Ejemplo 1: El siguiente código construye dinámicamente y ejecuta una sentencia SQL que sirve para buscar elementos cuyo nombre coincida con un texto determinado. La sentencia limita el número de elementos mostrados a aquéllos cuyo propietario coincida con el nombre de usuario del usuario actualmente autenticado.... String username = ctx.getauthenticatedusername(); String itemname = request.getparameter("itemname"); String query = "SELECT * FROM items WHERE owner = '" + username + "' AND itemname = '" + itemname + "'"; ResultSet rs = stmt.execute(query);... La sentencia que este código pretende ejecutar es la siguiente: SELECT * FROM items WHERE owner = <username> AND itemname = <itemname>; Sin embargo, y debido a que la sentencia es construida dinámicamente concatenando una cadena fija con cadenas procedentes de la entrada del usuario, la sentencia se comporta como es esperado sólo si <itemname> no contiene un carácter de comilla simple ( ). Si un atacante con nombre de usuario wiley introduce la cadena "name' OR 'a'='a'" para el parámetro <itemname>, entonces la sentencia resultante es la siguiente: Página 9

11 SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a'; Al añadir OR 'a'='a' a la cláusula WHERE, ésta siempre es evaluada a verdadero, por lo que la sentencia es lógicamente equivalente a la sentencia más simple: SELECT * FROM items; La simplificación de la sentencia permite al atacante saltarse el requerimiento de que sólo se deben devolver los elementos que pertenezcan al usuario autenticado. De esta forma, se devuelven todos los elementos de la tabla, independientemente de a qué usuario correspondan. Ejemplo 2: El siguiente ejemplo examina el efecto producido utilizando un valor malicioso distinto del usado en el ejemplo anterior. Si el atacante con nombre de usuario wiley introduce la cadena "name'; DELETE FROM items; --" para el parámetro <itemname>, entonces la sentencia se convierte en lo siguiente: SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name'; DELETE FROM items; --' Muchos servidores de bases de datos (por ejemplo, Microsoft SQL Server 2000) permiten que múltiples sentencias separadas por un punto y coma sean ejecutadas de una vez. Mientras que esta cadena maliciosa daría lugar a un error en Oracle y otros sistemas gestores de bases de datos que no permiten la ejecución por lotes de sentencias separadas por punto y coma, en los sistemas que sí lo permiten, este tipo de ataque permitiría a un atacante ejecutar comandos SQL arbitrarios contra la base de datos. Hay que hacer notar el par de guiones que se utilizan al final de la sentencia (--). La mayoría de los sistemas gestores de bases de datos interpretan estos caracteres como que el resto de la sentencia es un comentario y por lo tanto no debe ser ejecutada. En este caso, los caracteres de comentario sirven para anular el carácter de comilla simple que queda al final de la sentencia modificada. En los sistemas de bases de datos que no permiten que los caracteres de comentario sean utilizados de esta forma, el ataque todavía puede hacerse efectivo usando para ello un truco similar al del ejemplo 1. Si un atacante introduce la cadena "name'; DELETE FROM items; SELECT * FROM items WHERE 'a'='a'", entonces se crearán las siguientes tres sentencias válidas: SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name'; DELETE FROM items; SELECT * FROM items WHERE 'a'='a'; Un enfoque tradicional para prevenir este tipo de ataques de inyección SQL es tratarlos Página 10

12 como un problema de validación de datos de entrada y sólo aceptar los caracteres que se encuentran en una lista blanca de valores seguros o bien identificar y utilizar secuencias de escape sobre valores potencialmente maliciosos de una lista negra. El uso de listas blancas puede ser una forma efectiva de forzar reglas estrictas de validación, pero las sentencias SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías en lo que se refiere a la seguridad. En la mayoría de los casos, las listas negras están plagadas de omisiones que las hacen inefectivas para prevenir ataques de inyección SQL. Por ejemplo, un atacante puede: Dirigir el ataque a campos que no están contemplados en la lista negra. Encontrar formas de evitar la obligación de utilizar secuencias de escape con determinados caracteres. Utilizar procedimientos almacenados para ocultar los caracteres inyectados. La aplicación de secuencias de escape manualmente a las entradas de sentencias SQL puede ayudar en ocasiones, pero no es una forma efectiva de hacer las aplicaciones seguras frente a ataques de inyección SQL. Otra solución comúnmente propuesta para prevenir ataques de inyección SQL es utilizar procedimientos almacenados. A pesar de que los procedimientos almacenados pueden servir para prevenir ciertos tipos de ataques de inyección SQL, no pueden prevenir muchos otros tipos. Típicamente, los procedimientos almacenados ayudan a prevenir los ataques de inyección SQL limitando el tipo de sentencias que pueden pasarse como valores de sus parámetros. Sin embargo, hay muchas formas de saltarse estas limitaciones y hay muchas sentencias interesantes que sí pueden ser pasadas a los procedimientos almacenados. Por lo tanto, los procedimientos almacenados pueden evitar ciertos exploits, pero no hacen a la aplicación completamente segura frente a los ataques de inyección SQL. Recomendaciones La causa raíz de una vulnerabilidad de inyección SQL es la habilidad de un atacante para cambiar el contexto en una sentencia SQL, provocando que un valor que el programador pretendía fuese interpretado como datos sea interpretado como un comando. Cuando una sentencia SQL es construida, el programador sabe qué tiene que ser interpretado como datos y qué tiene que ser interpretado como parte de un comando. Las sentencias SQL parametrizadas pueden forzar este comportamiento, evitando así la práctica totalidad de los ataques por inyección SQL. Las sentencias SQL parametrizadas se construyen utilizando cadenas de SQL normal, pero en los puntos en los que se requiere incluir datos procedentes del usuario, se incluyen parámetros de enlace (bind parameters) que no son más que marcadores de posición (placeholders) para datos que se insertan posteriormente. En otras palabras, los parámetros de enlace permiten al programador especificar explícitamente qué debe ser tratado como datos y qué debe ser tratado como comandos. Cuando el programa está listo para ejecutar una sentencia, ésta proporciona al motor de base de datos los valores de los parámetros de enlace sin correr el peligro de que estos valores sean interpretados como parte de la sentencia. El ejemplo anteriormente utilizado puede ser reescrito usando sentencias SQL Página 11

13 parametrizadas (en vez de concatenando cadenas proporcionadas por el usuario):... String username = ctx.getauthenticatedusername(); String itemname = request.getparameter("itemname"); String query = "SELECT * FROM items WHERE itemname=? AND owner=?"; PreparedStatement stmt = conn.preparestatement(query); stmt.setstring(1, itemname); stmt.setstring(2, username); ResultSet results = stmt.execute(); En escenarios más complicados, que generalmente se encuentran en el ámbito de la generación de informes, se requiere que la entrada del usuario afecte a la estructura de la sentencia SQL, por ejemplo, añadiendo dinámicamente una restricción a una cláusula WHERE. No hay que utilizar esto como una excusa para concatenar directamente la entrada del usuario para crear la sentencia SQL. En estos casos se pueden prevenir los ataques de inyección SQL introduciendo un nivel de indirección adicional: crear un conjunto de cadenas legítimas que se correspondan con los distintos elementos que se deben incluir en la sentencia SQL; cuando se construya la sentencia, utilizar la entrada de usuario para seleccionar el elemento adecuado de esta lista de valores controlados. Un error habitual es utilizar sentencias SQL parametrizadas que se construyen concatenando cadenas introducidas por el usuario. Evidentemente, esto anula el propósito de las sentencias parametrizadas. Si no se está seguro de que las cadenas utilizadas para formar la sentencia SQL parametrizadas provienen de constantes controladas por la aplicación, no asuma que son seguras por el simple hecho de que no se ejecutan directamente como cadenas SQL. Investigue todos los usos de las cadenas controladas por el usuario en sentencias SQL y verifique que no pueden ser utilizadas para modificar el comportamiento de la sentencia Control de acceso Descripción Sin el control de acceso adecuado, ejecutar una sentencia SQL que contenga una clave primaria controlada por el usuario puede provocar que un atacante tenga acceso a registros que no está autorizado a ver. Los errores de control de acceso a base de datos se dan cuando: El programa recibe datos que proceden de una fuente no confiable. Los datos son utilizados para especificar el valor de una clave primaria en una sentencia SQL. Ejemplo 1: El siguiente código utiliza sentencias parametrizadas, que previenen ataques de tipo inyección SQL, para ejecutar una consulta que busca facturas que coincidan con el identificador proporcionado. El identificador se selecciona de una lista que contiene todas las facturas asociadas al usuario actualmente autenticado.... id = Integer.decode(request.getParameter("invoiceID")); Página 12

14 String query = "SELECT * FROM invoices WHERE id =?"; PreparedStatement stmt = conn.preparestatement(query); stmt.setstring(1, id); ResultSet results = stmt.execute();... El problema reside en que el programador no ha tenido en cuenta todos los posibles valores que puede tener el parámetro invoiceid. A pesar de que la interfaz de usuario presenta una lista con los identificadores de facturas que pertenecen al usuario actual, un atacante puede evitar la interfaz y hacer una petición especificando cualquier identificador de factura. Puesto que el código no comprueba que el usuario tenga permisos para ver la factura solicitada, mostrará cualquier factura, independientemente de que pertenezca o no al usuario autenticado. Recomendaciones En vez de confiar en la interfaz de usuario para restringir los valores que pueden ser enviados por el usuario, la aplicación y la capa de base de datos deben implementar un control de acceso. Bajo ninguna circunstancia se debe permitir que un usuario obtenga o modifique un registro de la base de datos sin tener los permisos adecuados. Esta política debe ser aplicada a toda consulta que llegue a la base de datos, lo cual puede hacerse simplemente incluyendo en la consulta el nombre de usuario del usuario actualmente autenticado. Ejemplo 2: El siguiente ejemplo implementa la misma funcionalidad que el ejemplo 1, pero impone una restricción adicional exigiendo que el usuario autenticado tenga acceso específico a la factura.... username = ctx.getauthenticatedusername(); id = Integer.decode(request.getParameter("invoiceID")); String query = "SELECT * FROM invoices WHERE id =? AND user =?"; PreparedStatement stmt = conn.preparestatement(query); stmt.setstring(1, id); stmt.setstring(2, username); ResultSet results = stmt.execute(); 3.2 Acceso al sistema de ficheros Manipulación de rutas Descripción Permitir que las entradas de usuario controlen las rutas utilizadas en operaciones con el sistema de ficheros puede permitir a un atacante acceder o modificar recursos que de otra manera estarían protegidos. Los errores de manipulación de rutas se dan cuando se cumplen las dos siguientes Página 13

15 condiciones: Un atacante puede especificar una ruta utilizada en una operación con el sistema de ficheros. Al especificar el recurso, el atacante adquiere unos privilegios que de otra forma no tendría. Por ejemplo, el programa puede dar a un atacante la posibilidad de sobrescribir un fichero o ejecutarse bajo una configuración controlada por el atacante. Ejemplo 1: El siguiente código utiliza la entrada procedente de una petición HTTP para crear el nombre de un fichero. El programador no ha considerado la posibilidad de que un atacante pueda especificar un nombre de fichero como "../../tomcat/conf/server.xml", lo que causaría que la aplicación sobrescribiese uno de sus ficheros de configuración. String rname = request.getparameter("reportname"); File rfile = new File("/usr/local/apfr/reports/" + rname);... rfile.delete(); Ejemplo 2: El siguiente código utiliza la entrada procedente de un fichero de configuración para determinar qué fichero tiene que abrir y devolver el contenido al usuario. Si la aplicación se ejecuta con determinados privilegios y un atacante puede modificar el fichero de configuración, podría utilizar la aplicación para leer cualquier fichero del sistema cuya extensión sea.txt. fis = new FileInputStream(cfg.getProperty("sub")+".txt"); amt = fis.read(arr); out.println(arr); Recomendaciones La mejor forma de evitar la manipulación de rutas es introducir un nivel de indirección: crear una lista de nombres de recursos legítimos que un usuario pueda especificar y únicamente permitir al usuario seleccionar de esta lista. De esta forma, la entrada del usuario nunca es utilizada directamente para especificar el nombre del recurso. En algunas situaciones, este enfoque no es práctico, porque la lista de nombres de recursos legítimos es demasiado larga. En estas ocasiones, los programadores suelen utilizar listas negras. Las listas negras rechazan de forma selectiva o bien aplican secuencias de escape a caracteres potencialmente peligrosos antes de utilizar la entrada del usuario. Sin embargo, cualquier lista negra tiene una alta probabilidad de ser incompleta y frecuentemente queda desfasada. Una mejor estrategia consiste en crear una lista blanca de los caracteres que están permitidos en el nombre del recurso y aceptar exclusivamente las entradas que contengan esos caracteres. Es notablemente difícil realizar una implementación adecuada de una lista negra. Si la lógica de validación recae en una lista negra, sea escéptico. Tenga en cuenta los distintos tipos de codificaciones de datos de entrada y los distintos tipos de metacaracteres que pueden tener un significado especial cuando son interpretados por Página 14

16 distintos sistemas operativos, bases de datos u otros recursos. Tenga en cuenta si la lista negra puede ser actualizada fácil, correcta y completamente si estos requerimientos cambian Inyección de comandos Descripción Ejecutar comandos procedentes de una fuente no confiable o en un entorno no confiable puede provocar que la aplicación ejecute comandos maliciosos en nombre del atacante. Las vulnerabilidades de inyección de comandos pueden adoptar dos formas: Un atacante puede modificar el comando que ejecuta una aplicación, controlando así explícitamente lo que el comando es. Un atacante puede modificar el entorno en el que se ejecuta un comando, controlando así implícitamente lo que el comando significa. Centrándonos principalmente en el primer escenario, es decir, la posibilidad de que un atacante pueda controlar el comando que se ejecuta, las vulnerabilidades de inyección de comandos de este tipo se producen cuando: 1. El programa recibe datos que proceden de una fuente no confiable. 2. Dichos datos son utilizados como parte de una cadena que representa el comando que es ejecutado por la aplicación. 3. Al ejecutar el comando, la aplicación otorga al atacante un privilegio o capacidad que de otra forma no tendría. Ejemplo 1: El siguiente código de una utilidad de sistema utiliza la propiedad de sistema APPHOME para determinar el directorio en el que está instalada y ejecutar un script de inicialización basado en una ruta relativa a dicho directorio.... String home = System.getProperty("APPHOME"); String cmd = home + INITCMD; java.lang.runtime.getruntime().exec(cmd);... El código en el ejemplo 1 permite a un atacante ejecutar comandos arbitrarios con el nivel de privilegios correspondiente a la aplicación simplemente modificando la propiedad de sistema APPHOME para que apunte a una ruta diferente que contenga una versión maliciosa de INITCMD. Debido a que la aplicación no valida el valor leído de la propiedad APPHOME, la aplicación puede ser engañada para que ejecute código malicioso que tome el control del sistema. Ejemplo 2: El siguiente código corresponde a una aplicación web de administración que permite a los usuarios realizar un backup de una base de datos Oracle utilizando para ello un script rmandb.bat que utiliza la utilidad rman y después un script cleanup.bat que Página 15

17 elimina algunos ficheros temporales. El script rmandb.bat acepta un único parámetro por línea de comandos que especifica qué tipo de backup realizar. Debido a que el acceso a la base de datos está restringido, la aplicación se ejecuta bajo un usuario con privilegios elevados.... String btype = request.getparameter("backuptype"); String cmd = new String("cmd.exe /K \"c:\\util\\rmandb.bat "+btype+"&&c:\\utl\\cleanup.bat\"") System.Runtime.getRuntime().exec(cmd);... El problema aquí es que el programa no hace ninguna validación sobre el valor del parámetro que se lee de la línea de comandos. Típicamente, la función Runtime.exec() no ejecuta comandos múltiples, pero en este caso el programa primero ejecuta el shell cmd.exe con el propósito de ejecutar múltiples comandos a través de una única llamada a Runtime.exec(). Una vez que se ha ejecutado el shell, éste ejecutará sin problemas múltiples comandos separados por &&. Si un atacante pasa una cadena con la forma "&& del c:\\dbms\\*.*", entonces la aplicación ejecutará este comando junto con cualquier otro especificado por el programa. Por las características de la aplicación, ésta se ejecuta con privilegios suficientes para interactuar con la base de datos, lo que significa que cualquier comando que el atacante logre inyectar se ejecutará también con estos privilegios. Ejemplo 3: El siguiente código corresponde a una aplicación web que da acceso a los usuarios a una interfaz a través de la cual pueden actualizar su contraseña en el sistema. Parte del proceso para actualizar contraseñas en determinados entornos de red consiste en ejecutar un comando make en el directorio /var/yp, para la cual sirve el siguiente código:... System.Runtime.getRuntime().exec("make");... El problema aquí está en que el programa no especifica una ruta absoluta para el comando make y en que falla al limpiar su entorno antes de ejecutar la llamada a Runtime.exec(). Si un atacante puede modificar la variable $PATH para apuntar a un binario malicioso llamado make, y forzar al programa a que sea ejecutado en esas condiciones, entonces el binario malicioso será cargado en vez del que se pretendía. Debido a las características de la aplicación, ésta se ejecuta con privilegios suficientes para ejecutar tareas de sistema, lo que significa que el binario make del atacante será ejecutado con esos privilegios, posiblemente otorgando al atacante control total sobre el sistema. Recomendaciones No permita a los usuarios tener control directo sobre los comandos que ejecuta una aplicación. En los casos en los que la entrada del usuario deba afectar al comando que se va a ejecutar, utilice la entrada sólo para realizar una selección de una lista predeterminada de comandos seguros. Si la entrada del usuario parece maliciosa, el Página 16

18 valor que se pase a la función que ejecuta el comando debe ser un valor por defecto que garantice que se elige un elemento seguro de la lista o bien se debe denegar completamente la ejecución del comando. En el caso de que se deba utilizar la entrada de usuario como argumento a un comando que será ejecutado por la aplicación, el enfoque anterior no es práctico, ya que se debería controlar una lista muy amplia de argumentos legítimos. En estas ocasiones, los programadores suelen utilizar listas negras. Las listas negras rechazan de forma selectiva o bien aplican secuencias de escape a caracteres potencialmente peligrosos antes de utilizar la entrada del usuario. Sin embargo, cualquier lista negra tiene una alta probabilidad de ser incompleta y es muy dependiente del sistema donde se ejecutan los comandos. Una mejor estrategia consiste en crear una lista blanca de los caracteres que están permitidos en las entradas de usuario y aceptar exclusivamente las entradas que contengan esos caracteres. Un atacante puede controlar indirectamente los comandos ejecutados por una aplicación modificando el entorno en el que dichos comandos se ejecutan. No se debe confiar en el entorno y se deben tomar precauciones para prevenir que un atacante pueda manipular dicho entorno para realizar un ataque. Siempre que sea posible, los comandos deben ser controlados por la aplicación y deben ser ejecutados utilizando una ruta absoluta. En los casos en los que la ruta no se conoce en tiempo de compilación (por ejemplo, aplicaciones multiplataforma), se debe construir una ruta absoluta durante la ejecución siempre a partir de valores confiables. Los valores y rutas pasadas a los comandos y que procedan de ficheros de configuración o de variables de entorno deben ser saneados y contrastados contra una lista de valores válidos. También se pueden realizar otras comprobaciones para detectar si la fuente de los datos ha sido manipulada. Por ejemplo, si un fichero de configuración es editable, el programa puede no ejecutarse. En los casos en los que se conoce con antelación la información sobre un binario que tiene que ser ejecutado, la aplicación debe verificar la identidad de dicho binario. Si un archivo binario debe pertenecer a un usuario determinado o tener una serie de permisos asignados, la aplicación debe comprobar estas condiciones programáticamente antes de ejecutar el binario. Aunque puede ser imposible proteger completamente un programa de un atacante con imaginación y totalmente volcado en controlar los comandos que ejecuta la aplicación, hay que estar seguro de aplicar siempre el principio de mínimo privilegio allí donde el programa ejecute un comando procedente de fuentes externas: nunca utilice o mantenga privilegios que no son estrictamente necesarios para la ejecución de dicho comando Uso indebido: Subida de archivos Descripción Dejar a los usuarios que suban ficheros puede permitir a los atacantes inyectar contenido o código malicioso en el servidor. Recomendaciones No se deben aceptar archivos adjuntos si se puede evitar. Si un programa tiene que Página 17

19 aceptar archivos adjuntos, debe restringir la posibilidad de que un atacante introduzca contenido malicioso controlando que se aceptan únicamente los tipos de contenidos específicos que el programa espera. La mayoría de los ataques que se basan en contenidos subidos requieren que el atacante pueda proporcionar contenido de su elección. Estableciendo restricciones en el contenido que el programa acepta, se limita en gran medida el abanico de posibles ataques. Revise los nombres de archivos, extensiones, y los contenidos para asegurarse que son los esperados y son aceptables para ser usados por la aplicación. Haga que resulte difícil para el atacante determinar el nombre y localización de los archivos subidos. Estas soluciones son, a menudo, específicas de cada programa y varían desde almacenar los archivos subidos en un directorio con un nombre generado a partir de un valor aleatorio cuando el programa se inicializa, a asignar a cada archivo subido un nombre aleatorio y que se guarde como entrada en una base de datos. 3.3 Gestión de logs Falsificación de log Descripción Si escribe entradas de usuario no validadas en los archivos de log, puede permitir a un atacante falsificar las entradas del log o inyectar contenido malicioso en el mismo. Recomendaciones Prevenir los ataques de falsificación del log con indirección: crear un conjunto de entradas de log legítimas que correspondan con diferentes eventos que deban ser registrados y sólo registrar entradas de este conjunto. Para capturar el contenido dinámico, como la salida de usuarios del sistema, siempre se deben utilizar valores controlados por el servidor en lugar de valores o datos proporcionados por el usuario. De esta forma, se asegura que las entradas que proporciona el usuario nunca serán directamente registradas en el log. En algunas situaciones este enfoque es impracticable, ya que el conjunto de entradas de log legítimas es demasiado grande o complejo. En estas situaciones, los desarrolladores suelen recurrir a listas negras. Las listas negras rechazan o evitan de forma selectiva caracteres potencialmente peligrosos antes de utilizar la entrada. Sin embargo, una lista de caracteres no seguros puede llegar a estar rápidamente incompleta o desactualizada. Un mejor enfoque es crear una lista blanca de caracteres que pueden aparecer en las entradas de log y aceptar exclusivamente caracteres del conjunto aprobado. El carácter más crítico en la mayoría de los ataques de falsificación del log es el carácter '\ n' (salto de línea), que nunca debe aparecer en una lista blanca de entradas de log. Muchas operaciones de registro de log se crean sólo con el propósito de depurar un programa durante las fases de desarrollo y pruebas. Basándose en la experiencia, la depuración se activará de forma accidental o a propósito en la fase de producción en algún momento, por lo que no puede servir de excusa el hecho de prevenir este tipo de ataques porque un programador piense No tengo planes de activar este log en Página 18

20 producción Usos indebidos Descripción En el desarrollo de la función de logging suelen llevarse a cabo malas prácticas que pueden derivar en vulnerabilidades de seguridad en la aplicación. Entre ellas, destacan las siguientes: No declarar logger como static final. El siguiente código declara incorrectamente el objeto logger como non-static. private final Logger logger = Logger.getLogger(MyClass.class); Utilizar múltiples loggers en una única clase en vez de distintos niveles de logging. En el siguiente ejemplo puede verse como, en la clase MyClass se declaran tres objetos de logger: public class MyClass { private final static Logger good = Logger.getLogger(MyClass.class); private final static Logger bad = Logger.getLogger(MyClass.class); private final static Logger ugly = Logger.getLogger(MyClass.class);... Utilizar System.out o System.err en vez de un log dedicado. El uso de estas funciones dificulta la monitorización del comportamiento de la aplicación. En el siguiente código de ejemplo se ve cómo se utiliza de forma incorrecta System.out: public class MyClass public static void main(string[] args) { System.out.println("hello world"); Mientras la mayoría de programadores adquieren conocimientos avanzados en distintos enfoques del lenguaje Java, un número sorprendente continúa escribiendo mensajes en la salida estándar utilizando System.out.println(). El problema se produce porque la escritura directa en la salida estándar se utiliza la mayoría de las veces como una forma no estructurada de logging. Las funciones de logging estructurado proporcionan características como niveles de logging, formato uniforme, timestamps, y quizá lo más crítico, la habilidad de registrar mensajes en el sitio adecuado. Cuando el uso de flujos de salida estándar del sistema se mezcla con el Página 19

21 código utilizado por logger, el resultado suele ser un log en el que se pierde información crítica. Además, la utilización de la salida estándar del sistema puede causar que los mensajes registrados sean devueltos accidentalmente a los usuarios finales, revelando información interna a los atacantes. La mayoría de los desarrolladores aceptan la necesidad del uso de un registro (logging) estructurado, pero muchos continúan utilizando la salida estándar en el desarrollo en preproducción. Si el código que se está revisando ha pasado las fases iniciales del desarrollo, el uso de System.out o System.err podría indicar un descuido en el cambio a un sistema estructurado de logging. Recomendaciones Es una buena práctica compartir un único objeto de tipo logger entre todas las instancias de una clase concreta y utilizar el mismo objeto logger en toda la duración del programa. Por ello, se recomienda declarar dicho objeto como static final. Se debe evitar el uso de la salida estándar del sistema a favor de un registro estructurado para facilitar el seguimiento del comportamiento de la aplicación y evitar posibles fugas de información del sistema a usuarios potencialmente maliciosos. 3.4 Configuración Contraseñas en ficheros de documentación Descripción Almacenar una contraseña en texto plano en un fichero de configuración tiene como consecuencia que cualquier usuario que tenga permisos de lectura sobre el fichero tenga acceso al recurso protegido por dicha contraseña. A veces los programadores creen que no hay forma de defender la aplicación de alguien que tiene acceso al fichero de configuración; sin embargo, esta actitud lo único que consigue es hacer más fácil el trabajo de un atacante. Las buenas prácticas de gestión de contraseñas dictaminan que una contraseña NUNCA debe ser almacenada en texto plano. Recomendaciones Una contraseña nunca debe ser almacenada en texto plano. En vez de eso, la contraseña debe ser introducida por un administrador en el momento de arrancar la aplicación o el sistema. Si esta estrategia no es viable, una alternativa más flexible pero menos segura es cifrar u ofuscar la contraseña y desperdigar la clave de encriptación a lo largo del sistema. De esta forma, un atacante tendrá que obtener y combinar correctamente múltiples elementos para descifrar la contraseña. Algunos productos hacen gala de gestionar las contraseñas de una forma más segura; por ejemplo, un servidor de aplicaciones comercial utiliza un simple XOR para ofuscar las contraseñas; sea escéptico respecto a este tipo de técnicas. Este y otros productos utilizan mecanismos de encriptación débiles o desfasados que son insuficientes para contextos en los que la seguridad es Página 20

22 crítica. Para una solución segura, la única opción viable es una propietaria Esquemas XML débiles Descripción Dejar un valor maxoccurs sin límite puede conducir a un agotamiento de recursos y, en última instancia, a una denegación del servicio. Procesar documentos XML puede resultar costoso en cuanto a consumo de recursos. Los atacantes pueden beneficiarse de esquemas que permiten elementos que no tienen ningún tipo de límite. De esta forma, pueden proporcionar a la aplicación un gran número de elementos provocando, así, que la aplicación agote los recursos del sistema. El siguiente es un ejemplo de esquema que permite un número ilimitado de elementos bar. <xs:schema xmlns:xs= > <xs:element name= foo > <xs:complextype> <xs:sequence> <xs:element name= bar maxoccurs= unbounded /> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Recomendaciones Se recomienda limitar maxoccurs a un número razonable. El siguiente es un ejemplo de esquema que permite un número limitado de 50 elementos bar. <xs:schema xmlns:xs= <xs:element name= foo > <xs:complextype> <xs:sequence> <xs:element name= bar maxoccurs= 50 /> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Página 21

23 3.5 Generación de contenido Web Cross-Site Scripting (XSS) Descripción Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando: La aplicación web recibe datos que proceden de una fuente no confiable. En el caso de XSS persistente (también conocido como XSS almacenado), la fuente no confiable es típicamente una base de datos u otro repositorio similar, mientras que en el caso de XSS reflejado la fuente no confiable suele ser la petición HTTP. Los datos son incluidos en el contenido dinámico que se devuelve al navegador del usuario sin haber comprobado que no contienen código malicioso. El posible contenido malicioso que puede ser enviado al navegador del usuario generalmente toma la forma de un bloque de código JavaScript, aunque también puede incluir HTML, Flash o cualquier otro tipo de código que pueda ser ejecutado por el navegador. La variedad de ataques XSS es amplísima, pero comúnmente incluyen la transmisión de datos privados como cookies u otra información de sesión hacia el atacante, la redirección de la víctima hacia contenido web controlado por el atacante, o la ejecución de otras acciones maliciosas en la máquina del usuario cuando accede a un sitio vulnerable. Ejemplo 1: El siguiente código JSP lee un identificador de empleado (eid) desde la petición HTTP y se lo muestra al usuario: <% String eid = request.getparameter("eid"); %>... Employee ID: <%= eid %> El código de este ejemplo funciona como es debido si el eid contiene únicamente caracteres alfanuméricos estándar. Si el valor del parámetro eid contiene metacaracteres o código fuente, entonces el código será ejecutado por el navegador del usuario al mostrar el contenido de la respuesta HTTP. Inicialmente, esto puede no parecer una vulnerabilidad. Después de todo por qué va a querer alguien introducir una URL que provoque la ejecución de código malicioso en su propia máquina? El verdadero peligro está en que el atacante puede crear la URL maliciosa y después, a través de correos electrónicos o ingeniería social, embaucar a las víctimas para que visiten un enlace a dicha URL. Cuando las víctimas pulsan el enlace, sin querer están reflejando el contenido malicioso a través de la aplicación web vulnerable a sus propias máquinas. Este mecanismo para explotar aplicaciones web vulnerables se conoce como XSS Reflejado. Ejemplo 2: El siguiente código JSP consulta una base de datos para obtener un empleado a partir de un identificador y mostrar el nombre del empleado. Página 22

24 <%... Statement stmt = conn.createstatement(); ResultSet rs = stmt.executequery( "select * from emp where id="+eid); if (rs!= null) { rs.next(); String name = rs.getstring("name"); %> Employee Name: <%= name %> Como en el caso del ejemplo 1, este código funciona como es debido cuando los valores de name son adecuados, pero no se hace nada para prevenir exploits en el caso de que no lo sean. De nuevo, este código puede parecer poco peligroso porque el valor de name se lee de la base de datos cuyos contenidos están aparentemente controlados por la aplicación. Sin embargo, si el valor de name se construye a partir de datos introducidos por el usuario, entonces la base de datos puede convertirse en un canal de contenido malicioso. Sin una validación adecuada de todos los datos contenidos en la base de datos, un atacante puede llegar a ejecutar código malicioso en el navegador del usuario que usa la aplicación web. Este tipo de exploit, conocido como XSS Persistente (o almacenado) es particularmente insidioso, ya que el nivel de indirección introducido por el repositorio de datos hace más complicado identificar la amenaza e incrementa la probabilidad de que el ataque afecte a múltiples usuarios. Esta forma de XSS tuvo sus comienzos con los sitios web que ofrecían libros de visitas a los usuarios. Los atacantes pueden introducir código JavaScript en una entrada del libro de visitas con lo que todos los usuarios que visiten el libro posteriormente, ejecutarán el código malicioso. Como demuestran los ejemplos anteriores, las vulnerabilidades XSS son provocadas por código que incluye datos no validados en una respuesta HTTP. Existen tres vectores a través de los cuales un ataque XSS puede alcanzar a una víctima: Como en el ejemplo 1, datos que se leen directamente de la petición HTTP y son reflejados de nuevo en la respuesta HTTP. Los exploits de vulnerabilidades XSS Reflejado se dan cuando un atacante provoca que un usuario proporcione contenido malicioso a una aplicación web vulnerable, que es de nuevo reflejado hacia el usuario y ejecutado en su navegador. El mecanismo más común para distribuir contenido malicioso es incluirlo como parámetro en una URL que es publicada o enviada por correo electrónico a las víctimas. Las URLs construidas de esta forma constituyen la base de muchos esquemas de phising, en los que el atacante convence a la víctima para visitar una URL que apunta a un sitio web vulnerable. Después de que el sitio web refleja el contenido malicioso hacia el navegador del usuario, dicho contenido es ejecutado y puede, por ejemplo, transferir datos privados como cookies que pueden contener información Página 23

25 de sesión desde la máquina de la víctima a la del atacante, o realizar otras acciones maliciosas. Como en el ejemplo 2, la aplicación almacena datos peligrosos en una base de datos o cualquier otro repositorio en el que se confía. Estos datos peligrosos son posteriormente leídos de nuevo por la aplicación e incluidos en el contenido dinámico. Los exploits de las vulnerabilidades de tipo XSS Persistente ocurren cuando un atacante es capaz de incluir contenido malicioso en un repositorio de datos y después este contenido es incluido en contenido dinámico devuelto al navegador de la víctima. Desde el punto de vista del atacante, el lugar óptimo para insertar contenido malicioso es un área que sea mostrada a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente tienen privilegios elevados en la aplicación o interactúan con datos sensibles que pueden ser valiosos para el atacante. Si uno de estos usuarios ejecuta código malicioso, el atacante puede ser capaz de ejecutar una operación privilegiada en nombre del usuario o conseguir acceder a datos sensibles que pertenecen al usuario. Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro repositorio; estos datos son posteriormente leídos por la aplicación como datos confiables e incluidos en contenido dinámico. Recomendaciones La solución a las vulnerabilidades XSS consiste en asegurarse de que se realizan validaciones en los puntos adecuados y que se comprueban las propiedades correctas. Dado que las vulnerabilidades XSS se dan cuando una aplicación incluye datos maliciosos en la salida que genera, un enfoque habitual es validar los datos justo antes de que abandonen la aplicación. Sin embargo, puesto que las aplicaciones web generan contenido dinámico a través de código de cierta complejidad este enfoque es propenso a omitir ciertas validaciones. Una forma efectiva de mitigar este riesgo es realizar también validaciones sobre los datos de entrada a la aplicación. Las aplicaciones web deben validar sus entradas para prevenir otro tipo de vulnerabilidades, como las vulnerabilidades de inyección SQL, por lo que ampliar estos mecanismos de validación para incluir comprobaciones relativas a XSS es relativamente fácil. A pesar de su valor, la validación de datos de entrada no sustituye una validación rigurosa de los datos de salida. Una aplicación puede aceptar datos a través de un repositorio de datos compartido u otra fuente confiable; sin embargo, esta fuente de datos puede aceptar datos de entrada de otra fuente que no realiza una validación adecuada de los datos introducidos. Como consecuencia, la aplicación no puede confiar implícitamente en la seguridad de estos datos. Esto significa que la mejor forma de prevenir las vulnerabilidades XSS es validar todo lo que entre a la aplicación y todo lo que salga de la aplicación con destino al usuario. La estrategia más segura para incluir validaciones XSS es crear una lista blanca de caracteres que están permitidos que aparezcan en el contenido HTTP, y por lo tanto, aceptar únicamente las entradas formadas por caracteres que se encuentran en dicha lista. Por ejemplo, un nombre de usuario debe estar formado únicamente por caracteres Página 24

26 alfanuméricos, un número de teléfono debe incluir sólo los dígitos 0-9. Sin embargo, este enfoque puede ser inviable en muchas aplicaciones web ya que muchos caracteres que tienen un significado especial para el navegador deben ser considerados como entradas válidas una vez que son codificados, como por ejemplo, aplicaciones web en las que se permite al usuario introducir código HTML. Un enfoque más flexible, pero también menos seguro, es utilizar listas negras que permitan rechazar de forma selectiva o aplicar secuencias de escape sobre caracteres potencialmente peligrosos antes de aceptar una entrada. Para poder construir este tipo de listas, primero es necesario conocer qué caracteres tienen un significado especial para los navegadores. Aunque el estándar HTML define qué caracteres tienen un significado especial para un navegador, muchos navegadores tratan de corregir determinados problemas o limitaciones de HTML tratando determinados caracteres como especiales en determinados contextos. El CERT Coordination Center del Software Engineering Institute (ESI) de la Universidad Carnegie Mellon proporciona la siguiente información sobre caracteres especiales en determinados contextos: En el contexto de un elemento de nivel de bloque (en el medio de un párrafo de texto): "<" es especial porque comienza un tag. "&" es especial porque introduce una entidad de carácter (character entity). ">" es especial porque algunos navegadores lo tratan como tal, asumiendo que el autor de la página pretendía incluir un carácter de apertura de tag <, pero fue omitido por error. Los siguientes principios se aplican a los valores de los atributos: Si el valor de un atributo está encerrado entre dobles comillas, las dobles comillas son especiales porque marcan el final del valor del atributo. Si el valor de un atributo está encerrado entre comillas simples, las comillas simples son especiales porque marcan el final del valor del atributo. En valores de atributos sin comillas, los caracteres de tipo espacio en blanco como espacios y tabuladores, son especiales. & es especial cuando se usa en determinados atributos, porque introduce una entidad carácter. En URLs, por ejemplo, un motor de búsqueda puede proporcionar un enlace dentro de la página de resultados que puede ser pulsado por el usuario para relanzar la búsqueda. Esto puede ser implementado codificando los parámetros de la búsqueda en la propia URL, lo cual introduce caracteres especiales adicionales: Los caracteres espacio, tabulador y nueva línea son especiales porque marcan el final de la URL. & es especial porque introduce una entidad carácter o actúa como separador de parámetros. Los caracteres no ASCII (es decir, todos los que están por encima de 128 en la codificación ISO ) no se permiten en las URLs, por lo que son considerados especiales en este contexto. Página 25

27 El símbolo % debe ser filtrado de la entrada siempre que parámetros codificados con secuencias de escape HTTP sean decodificados por código de servidor. Por ejemplo, el carácter % debe ser filtrado de una entrada como "%68%65%6C%6C%6F" y debe aparecer como hello en la página web en cuestión. En el cuerpo de un bloque <SCRIPT></SCRIPT>: El punto y coma, los paréntesis, las llaves y el carácter de nueva línea deben ser filtrados en aquellas situaciones en las que el texto pueda ser insertado en un tag <script> que ya existía. En scripts de servidor: Se requiere un filtrado adicional en los scripts de servidor que convierten cualquier carácter de exclamación (!) existente en una entrada a carácter de comilla doble ( ) en una salida. Otras posibilidades: Si un atacante envía una petición codificada en UTF-7, el carácter especial < aparece como +ADw- y puede saltarse el filtrado. Si la salida se incluye en una página que no especifica explícitamente una codificación, algunos navegadores intentarán identificar la codificación basándose en el contenido (en este caso, UTF-7). Una vez que se han identificado los puntos de una aplicación donde se deben hacer las validaciones XSS y se tienen claros qué caracteres deben ser considerados en estas validaciones, el siguiente paso es considerar cómo las rutinas de validación van a manejar estos caracteres especiales. Si los caracteres especiales no se consideran como una entrada válida a la aplicación, una opción es rechazar cualquier petición que contenga estos caracteres. Una segunda opción, es eliminar los caracteres especiales de la entrada aplicando un filtro, aunque esto tiene el inconveniente de que se cambia la representación visual del contenido filtrado, lo que puede ser inaceptable en los casos en los que se requiera mantener la integridad de la entrada para ser mostrada. Si la entrada que contiene caracteres especiales debe ser aceptada y mostrada, la rutina de validación debe codificar cualquier carácter especial para suprimir su significado. La especificación oficial de HTML proporciona una lista completa de valores ISO codificados. Muchos servidores de aplicaciones intentan limitar la exposición de una aplicación a vulnerabilidades XSS proporcionando para ello implementaciones especiales de las funciones responsables de establecer los contenidos de una respuesta HTTP; estas funciones realizan validaciones en busca de caracteres especiales que puedan suponer un ataque XSS. Sin embargo, no se fíe del servidor de aplicaciones para hacer su aplicación segura; cuando se desarrolla una aplicación, no existe una garantía absoluta sobre qué servidores de aplicaciones va a ejecutarse. A medida que los estándares y exploits conocidos evolucionan, no hay garantía de que los servidores de aplicaciones evolucionen de la misma forma. Página 26

28 3.5.2 Manipulación de cabeceras Descripción Incluir datos sin validar en la cabecera de respuesta HTTP puede permitir ataques de envenenamiento de caché, Cross-Site Scripting, Cross-User Defacement, Page Hijacking, manipulación de cookies u Open redirect. Las vulnerabilidades de manipulación de cabeceras ocurren cuando: 1. Se introducen datos a una aplicación web a través de una fuente no confiable, frecuentemente en una petición HTTP. 2. Los datos se incluyen en una cabecera de respuesta HTTP y se envían a un usuario de la web sin validar. Al igual que con muchas vulnerabilidades de seguridad, la manipulación de cabeceras es un medio para un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa los datos maliciosos a una aplicación vulnerable, y la aplicación incluye los datos en la cabecera de respuesta HTTP. Uno de los ataques más común de la manipulación de cabeceras es HTTP Response Splitting. Para explotar con éxito un HTTP Response Splitting, la aplicación debe permitir entradas que contengan caracteres CR (retorno de carro: %0d o \r) y LF (salto de línea: %0a o \n) en la cabecera. Estos caracteres no sólo dan el control a los atacantes de las cabeceras restantes y del cuerpo de la respuesta que la aplicación intenta enviar, sino que también les permite crear respuestas adicionales completamente bajo su control. Ejemplo: El siguiente fragmento de código lee el nombre del autor de una entrada en un weblog desde una petición HTTP y lo almacena en la cabecera de una cookie de una respuesta HTTP. String author = request.getparameter(author_param);... Cookie cookie = new Cookie( author, author); cookie.setmaxage(cookieexpiration); response.addcookie(cookie); Supongamos que una cadena formada por caracteres alfanuméricos, tales como Jane Smith, es enviada en la petición. La respuesta HTTP que incluya esta cookie tendría la siguiente forma: HTTP/ OK... Set-Cookie: author = Jane Smith... Sin embargo, debido a que el valor de la cookie está formado por la entrada de usuario sin validar, la respuesta sólo mantendrá esta forma si el valor enviado para AUTHOR_PARAM no contiene caracteres CR y LF. Si un atacante envía una cadena maliciosa, como Wiley Hacker\r\nHTTP/ OK\r\n..., entonces la respuesta HTTP se dividiría en dos respuestas de la siguiente forma: HTTP/ OK Página 27

29 ... Set-Cookie: author = Wiley Hacker HTTP/ OK... Es evidente que la segunda respuesta está completamente controlada por el atacante y se puede construir con cualquier cabecera y contenido del cuerpo deseado. La habilidad del atacante para construir arbitrariamente las respuestas HTTP permite una variedad de ataques, incluyendo: Cross-User Defacement, envenenamiento de caché, Cross-Site Scripting, Page Hijacking, manipulación de cookies y Open redirect Cross- User Defacement: Un atacante puede hacer una petición simple a un servidor vulnerable que obligará al servidor a crear dos respuestas, la segunda será mal interpretada como una respuesta a una petición diferente, posiblemente como una hecha por otro usuario que comparta la misma conexión TCP con el servidor. Esto se puede hacer convenciendo al usuario para que envíen ellos mismos las peticiones maliciosas o, de forma remota, en situaciones donde el atacante y el usuario compartan una conexión TCP común con el servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sido hackeada, consiguiendo que los usuarios pierdan la confianza en la seguridad de la aplicación. En el peor de los casos, un atacante puede proporcionar contenido malicioso especialmente diseñado para imitar el comportamiento de la petición, pero redireccionando la información privada, tales como números de cuenta y contraseñas, al atacante. Envenenamiento de caché: El impacto de la respuesta construida maliciosamente se puede ampliar si se almacena en caché, ya sea en una caché web que es utilizada por varios usuarios, o incluso en la caché del navegador de un usuario único. Si una respuesta se almacena en una caché web compartida, como las que se encuentran en los servidores proxy, entonces todos los usuarios de esa caché continuarán recibiendo contenido malicioso hasta que la entrada de la caché sea eliminada. Del mismo modo, si la respuesta está en la caché de un navegador de un usuario individual, entonces ese usuario continuará recibiendo el contenido malicioso hasta que la entrada de la caché sea eliminada, aunque sólo el usuario de la instancia local del navegador se verá afectado. Page Hijacking: Además de usar una aplicación vulnerable para enviar contenido malicioso al usuario, la misma vulnerabilidad puede también ser aprovechada para redirigir contenido sensible generado por el servidor al atacante, en lugar de al usuario al que va destinado. Mediante el envío de una petición que da lugar a dos respuestas: la respuesta desde el servidor y la respuesta generada por el atacante, un atacante puede hacer que un nodo intermedio, como un servidor proxy compartido, desvíe al atacante una respuesta generada por el servidor para el usuario. Debido a que la petición formulada por el atacante genera dos respuestas, la primera es interpretada como una respuesta a la petición del atacante, mientras que la segunda permanece en el limbo. Cuando el usuario hace una petición legítima por medio de la misma conexión TCP, la petición del atacante está esperando y es interpretada como una respuesta a la petición de la víctima. El atacante entonces envía una segunda petición al servidor, a la que el servidor proxy responde con la petición generada por el servidor y destinada a la Página 28

30 víctima, poniendo así en peligro la información sensible en las cabeceras o en el cuerpo de la respuesta destinada a la víctima. Manipulación de cookies: Cuando se combina con ataques como Cross-Site Request Forgery, los atacantes pueden modificar, añadir o sobrescribir las cookies de un usuario legítimo. Open Redirect: Permitir entradas sin validar para controlar la URL utilizada en una redirección, puede ayudar a realizar ataques de phishing. Muchos de los servidores de aplicaciones actuales previenen la inyección de caracteres maliciosos en las cabeceras HTTP. Por ejemplo, versiones recientes de Apache Tomcat lanzan una excepción IllegalArgumentException si se intenta configurar una cabecera con caracteres prohibidos. Si su servidor de aplicaciones impide configurar cabeceras con caracteres de nueva línea, entonces su aplicación no es vulnerable a HTTP Response Splitting. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede dejar una aplicación vulnerable a la manipulación de cookies u Open Redirects, así que debe tenerse cuidado al configurar las cabeceras HTTP con la entrada del usuario. Recomendaciones La solución a la manipulación de cabeceras es asegurarse de que la validación de la entrada se produce en los lugares adecuados y que verifica las propiedades correctas. Dado que las vulnerabilidades de manipulación de cabeceras ocurren cuando una aplicación incluye información maliciosa en su salida, un enfoque lógico sería validar la información inmediatamente antes de abandonar la aplicación. Sin embargo, debido a que las aplicaciones web a menudo tienen código complejo para generar las respuestas dinámicamente, este método es propenso a errores de omisión. Una forma efectiva de mitigar este riesgo es llevar a cabo validación de entradas para la manipulación de las cabeceras. Las aplicaciones web deben validar su entrada para evitar otras vulnerabilidades, como inyección SQL, así que aumentar el mecanismo de validación de entrada existente en una aplicación para que incluya comprobaciones sobre la manipulación de las cabeceras, en general, es relativamente fácil. A pesar de su valor, la validación de entrada para la manipulación de cabeceras no sustituye a una rigurosa validación de la salida. Una aplicación puede aceptar la entrada a través de un almacén de datos compartidos o de otra fuente confiable, y ese almacén de datos puede aceptar entradas de una fuente que no valida adecuadamente la entrada. Por lo tanto, la aplicación no puede confiar, de forma implícita, en la seguridad de éste ni de cualquier otro dato. Esto significa que la mejor forma de prevenir las vulnerabilidades de la manipulación de cabeceras es la de validar todo lo que entra o sale de la aplicación destinada al usuario. El método más seguro para la validación de la manipulación de cabeceras es crear una lista blanca de caracteres seguros que puedan aparecer en la cabecera de la respuesta HTTP y aceptar la entrada compuesta exclusivamente de caracteres del conjunto aprobado. Por ejemplo, un nombre válido sólo puede incluir caracteres alfanuméricos o un número de cuenta sólo puede incluir dígitos en el rango 0-9. Un enfoque más flexible, pero menos seguro, es conocido como lista negra, que rechaza de forma selectiva o evita caracteres potencialmente peligrosos antes de usar Página 29

31 la entrada. Para formar dicha lista, primero es necesario entender el conjunto de caracteres que tienen significado especial en las cabeceras de respuestas HTTP. Aunque los caracteres CR y LF son la esencia del ataque HTTP response splitting, otros caracteres, como : (dos puntos) y = (igual), tienen especial significado también en las cabeceras de las respuestas. Una vez identificados los puntos correctos en una aplicación para realizar la validación de los ataques de la manipulación de la cabecera y qué caracteres especiales se deben considerar en la validación, el siguiente paso es identificar cómo la validación maneja los caracteres especiales. La aplicación debería rechazar cualquier entrada destinada a ser incluida en las cabeceras de la respuesta HTTP que contenga caracteres especiales, particularmente CR y LF. Muchos servidores de aplicaciones intentan limitar la exposición de una aplicación a las vulnerabilidades HTTP response splitting proporcionando implementaciones para las funciones responsables de configurar las cabeceras HTTP y las cookies que realizan la validación de los caracteres esenciales en un ataque HTTP response splitting. No confíe en que el servidor donde se ejecuta la aplicación lo hace de forma segura. Cuando una aplicación es desarrollada, no hay garantías sobre en qué servidores de aplicaciones se ejecutará a lo largo de toda su vida útil. Como los estándares y las vulnerabilidades conocidas evolucionan, no hay garantías de que los servidores de aplicaciones también estén sincronizados Cross-Site Request Forgery Descripción Los formularios enviados a una aplicación web deben contener un secreto específico del usuario para prevenir que un atacante pueda realizar peticiones no autorizadas. Una vulnerabilidad de tipo Cross-Site Request Forgery (CSRF) se da cuando: 1. Una aplicación web utiliza cookies de sesión. 2. La aplicación procesa una petición HTTP sin verificar que ésta fue hecha con el consentimiento del usuario. Si una petición no contiene un nonce (valor de seguridad) que pruebe su procedencia, el código que gestiona la petición es vulnerable a un ataque CSRF (a menos que la petición no cambie el estado de la aplicación). Esto significa que una aplicación web que utilice cookies de sesión tiene que tomar precauciones especiales para evitar que un atacante engañe a los usuarios para realizar peticiones falsas. Imagine una aplicación web alojada en un dominio example.com que permite a los administradores crear cuentas de usuario por medio del envío del siguiente formulario: <form method="post" action="/new_user" > Name of new user: <input type="text" name="username"> Password for new user: <input type="password" name="user_passwd"> <input type="submit" name="action" value="create User"> </form> Un atacante puede crear un sitio web con una página que contenga el siguiente código: <form method="post" action=" Página 30

32 <input type="hidden" name="username" value="hacker"> <input type="hidden" name="user_passwd" value="hacked"> </form> <script> document.usr_form.submit(); </script> Si un administrador de example.com visita la página maliciosa mientras tiene una sesión activa, estará creando una cuenta para el atacante si darse cuenta. Esto es un ataque Cross-Site Request Forgery. Esto es posible porque la aplicación no tiene forma de determinar la procedencia de la petición. Cualquier petición puede ser una acción procedente de un usuario legítimo o una acción maliciosa procedente de un atacante. El atacante no puede ver la página que genera la petición maliciosa, por lo que esta técnica de ataque sólo tiene sentido para peticiones que modifican el estado de la aplicación. Recomendaciones Por lo tanto, para evitar las vulnerabilidades CSRF, las aplicaciones que usan cookies de sesión deben incluir algún elemento distintivo en cada petición para permitir al código de servidor validar la procedencia de la petición. Una forma de implementar esto es incluyendo identificadores de petición aleatorios en los formularios. <form method="post" action="/new_user" > Name of new user: <input type="text" name="username"> Password for new user: <input type="password" name="user_passwd"> <input type="submit" name="action" value="create User"> </form> <input type="hidden" name="req_id" value="87ae34d92ba7a1"> De esta forma, el código de servidor puede validar el identificador de la petición antes de proceder con el procesamiento del resto de los datos. El identificador de petición puede ser único para cada nuevo formulario o puede ser compartido por todos los formularios para una sesión en particular. Al igual que ocurre con los identificadores de sesión, cuanto más difícil sea para un atacante averiguar el identificador de petición, más difícil será para él realizar con éxito un ataque CSRF. Por otro lado, la mayoría de los navegadores web envían una cabecera HTTP llamada referer con cada petición. Se supone que esta cabecera contiene la URL de la página que ha generado la petición, pero un atacante puede fácilmente falsificar esta información, por lo que la cabecera referer no es útil para determinar la procedencia de la petición. Las aplicaciones que pasan el identificador de sesión en la URL en vez de usar una cookie, no son vulnerables a CSRF ya que no hay forma de que el atacante acceda a la información de sesión y la incluya en una petición. Página 31

33 3.6 Criptografía Encriptación débil Descripción El programa utiliza un algoritmo de encriptación débil que no puede garantizar la confidencialidad de datos sensibles. Algoritmos anticuados de encriptación, como DES, ya no proporcionan suficiente protección para ser usados con datos sensibles. Los algoritmos de encriptación se basan en el tamaño de la clave como uno de los mecanismos principales para asegurar la fortaleza criptográfica. La fortaleza criptográfica se mide, a menudo, por el tiempo y potencia de cálculo necesarios para general una clave válida. Los avances en potencia de cálculo han hecho que sea posible obtener claves de encriptación pequeñas en una cantidad de tiempo razonable. Por ejemplo, las claves de 56-bit utilizadas en el algoritmo DES supusieron un obstáculo significativo para el cálculo en los años 70, cuando se desarrolló el algoritmo por primera vez, pero hoy DES puede ser descifrado en menos de un día utilizando equipos disponibles comúnmente. Recomendaciones Se recomienda utilizar algoritmos de encriptación fuerte con claves de gran tamaño para proteger datos sensibles. Ejemplos de alternativas fuertes a DES son Rijndael (Advanced Encryption Standard o AES) y Triple DES (3DES). Antes de seleccionar un algoritmo, primero se debería determinar si la organización sigue algún estándar en cuanto a algoritmos específicos y su implementación. En esta auditoría se ha reportado una vulnerabilidad alta de seguridad al utilizar algoritmos RC4 o DES y una vulnerabilidad baja al utilizar un algoritmo RC Control de acceso Fijación de sesión Descripción Las vulnerabilidades de fijación de sesión se producen cuando: 1. Una aplicación web autentica a un usuario sin validar previamente la sesión existente, dando así continuidad a la utilización de la sesión asociada ya con el usuario. 2. Un atacante es capaz de forzar un identificador de sesión conocido de un usuario de forma que una vez que el usuario se autentica, el atacante tenga acceso a la sesión autenticada. En la imagen que se encuentra a continuación, puede verse el proceso general de ataque seguido para explotar este tipo de vulnerabilidades. Página 32

34 (1) El atacante puede establecer una conexión legítima con el servidor web, el cual (2) establece un identificador de sesión, o bien crear una nueva sesión con el identificador de sesión propuesto. Después (3) el atacante envía un enlace a la víctima con el identificador de la sesión establecida al que la víctima accede (4), el servidor Web observa que la sesión ya estaba establecida y no necesita crear una nueva, (5) la víctima proporciona sus credenciales al servidor, y por último el atacante, que conoce el identificador de sesión accede a la cuenta de la víctima. Recomendaciones Para prevenir la fijación de sesión, una aplicación web debe emitir un nuevo identificador de sesión, al mismo tiempo que autentica a un usuario. Muchos servidores de aplicación dificultan esta tarea proporcionando funcionalidades independientes de gestión de la autorización y de gestión de sesión. Por ejemplo, una aplicación que fija directamente en el post datos de autenticación a la URL j_security_check del contenedor de Servlet detomcat provocará que el servidor realice la autenticación sin emitir un nuevo identificador de sesión. Se recomienda implementar código propio que realice la autenticación asegurando que se invalida la sesión existente antes de procesar las peticiones de login. Cualquier información del usuario almacenada en la sesión puede ser migrada a la nueva sesión de manera segura, siempre y cuando el identificador de sesión asociado cambie. Página 33

35 3.8 Diseño Condición de carrera: Variable miembro Singleton Descripción Las variables miembro de un servlet pueden permitir que un usuario vea los datos de otro usuario. Muchos programadores de servlets no entienden que, a menos que un servlet implemente la interface SingleThreadModel, el servlet es un Singleton. Es decir, existe una única instancia del servlet, y esa instancia es reutilizada para gestionar múltiples peticiones que son procesadas simultáneamente por distintos hilos de ejecución. Un resultado común de este desconocimiento, es que los desarrolladores usan las variables miembro de un servlet de tal forma que un usuario puede ver los datos de otro usuario. En otras palabras, almacenar datos de usuario en las variables miembro de un servlet produce una condición de carrera. Ejemplo 1: El siguiente servlet almacena el valor de un parámetro procedente de la petición HTTP en una variable miembro y, posteriormente, incluye ese valor en la respuesta. public class GuestBook extends HttpServlet { String name; protected void dopost (HttpServletRequest req, HttpServletResponse res) { name = req.getparameter("name");... out.println(name + ", thanks for visiting!"); Este código funciona perfectamente en un entorno con un único usuario. Sin embargo, si dos usuarios acceden al servlet prácticamente en el mismo instante, es posible que los dos hilos de ejecución que están procesando las peticiones se entremezclen de la siguiente forma: Hilo 1: asigna "Dick" a la variable name. Hilo 2: asigna "Jane" a la variable name. Hilo 1: muestra Jane, thanks for visiting!" Hilo 2: muestra Jane, thanks for visiting!" Con lo que se muestra al primer usuario el mensaje conteniendo el nombre del segundo usuario. Recomendaciones No utilice las variables miembro de un servlet para otra cosa que no sean constantes (por ejemplo, hacer todas las variables miembro static final). Los programadores tienden a utilizar las variables miembro de un servlet para contener datos de usuario cuando necesitan trasladar datos desde una región del código a otra. Página 34

36 Si éste es el propósito, considere utilizar una clase separada y utilice el servlet únicamente para envolver dicha clase. Ejemplo 2: El defecto en el ejemplo anterior puede ser corregido de la siguiente forma: public class GuestBook extends HttpServlet { protected void dopost (HttpServletRequest req, HttpServletResponse res) { GBRequestHandler handler = new GBRequestHandler(); handler.handle(req, res); public class GBRequestHandler { String name; public void handle(httpservletrequest req, HttpServletResponse res) { name = req.getparameter("name");... out.println(name + ", thanks for visiting!"); Alternativamente un servlet puede implementar la interface SingleThreadModel, lo que hace que el contenedor de servlets mantenga un pool de objetos servlet los cuales va utilizando para gestionar las peticiones entrantes. Dependiendo de cómo esté implementado el contenedor de servlets y de las necesidades de la aplicación, el uso de SingleThreadModel puede causar problemas de rendimiento Almacenar objetos no serializables en sesión Descripción El almacenamiento de un objeto no serializable como un atributo de HttpSession puede dañar la fiabilidad de la aplicación. Ejemplo: La siguiente clase se añade a la sesión, pero al no ser serializable, dicha sesión no podrá ser replicada: public class DataGlob { String globname; String globvalue; public void addtosession(httpsession session) { session.setattribute("glob", this); Página 35

37 Recomendaciones Una aplicación J2EE puede hacer uso de múltiples máquinas virtuales de java con el fin de mejorar la fiabilidad y el rendimiento de la aplicación. Para conseguir que las distintas máquinas virtuales de java aparezcan como una sola aplicación de cara al usuario, el contenedor J2EE puede replicar un objeto HttpSession a través de las múltiples máquinas virtuales de forma que si una de las máquinas llega a estar no disponible, otra puede sustituirla sin interrumpir el flujo de la aplicación. Los valores que la aplicación almacena como atributos en la sesión deben implementar el interfaz Serializable para poder trabajar con la sesión replicada. 3.9 Gestión de recursos Recurso no liberado Descripción La aplicación puede no liberar un recurso del sistema. Las causas habituales de las fugas de recursos son las siguientes: Condiciones de error y otras circunstancias excepcionales. Confusión acerca de qué parte del programa es responsable de liberar un recurso. La mayor parte de las incidencias relacionadas con recursos no liberados originan problemas de fiabilidad en la aplicación, pero si un atacante puede provocar intencionadamente una fuga de recursos, podría llegar a realizar un ataque de denegación de servicio al agotar el pool de recursos. Los tipos de recursos que el sistema puede no liberar son los siguientes: Flujos Bases de datos Sockets Ficheros A continuación se detallan ejemplos de código en los que se podría producir una fuga de recursos. Dichos ejemplos se encuentran divididos en función del tipo de recurso al que afectan: FLUJOS: El siguiente método nunca cierra el handle a fichero que abre inicialmente. El método finalize() de FileInputStream eventualmente llama al método close(), pero no existe garantía de cuánto tiempo pasará antes de que se llame a finalize(). En un entorno con carga elevada, puede darse el caso de que la máquina virtual de Java llegue a agotar los handles a fichero. private void processfile(string fname) throws FileNotFoundException, IOException { FileInputStream fis = new FileInputStream(fName); int sz; Página 36

38 byte[] bytearray = new byte[block_size]; while ((sz = fis.read(bytearray))!= -1) { processbytes(bytearray, sz); BASES DE DATOS: En condiciones normales, el código siguiente ejecuta una consulta contra la base de datos, procesa los resultados devueltos y cierra el objeto Statement utilizado. Sin embargo, si se produce una excepción mientras se ejecuta la sentencia SQL o se procesan los resultados, el objeto Statement no se cerrará nunca. Si esto se produce con mucha frecuencia, la base de datos se quedará sin cursores que utilizar y no podrá ejecutar más sentencias SQL. Statement stmt = conn.createstatement(); ResultSet rs = stmt.executequery(cxn_sql); harvestresults(rs); stmt.close(); SOCKETS: El siguiente método nunca cierra el socket que abre. En un entorno donde se produzcan muchas peticiones esto puede derivar en el agotamiento de todos los sockets. private void echosocket(string host, int port) throws UnknownHostException, SocketException, IOException { Socket sock = new Socket(host, port); BufferedReader reader = new BufferedReader(new InputStreamReader(sock.getInputStream())); while ((String socketdata = reader.readline())!= null) { System.out.println(socketData); En condiciones normales, el siguiente código cerrará el socket y cualquier flujo asociado. Pero si ocurre una excepción mientras se está leyendo la entrada o escribiendo datos en pantalla el socket no será cerrado. Si esto ocurre con suficiente frecuencia, el sistema se quedará sin sockets y no será capaz de manejar nuevas conexiones. private void echosocket(string host, int port) throws UnknownHostException, SocketException, IOException { Socket sock = new Socket(host, port); BufferedReader reader = new BufferedReader(new InputStreamReader(sock.getInputStream())); Página 37

39 while ((String socketdata = reader.readline())!= null) { System.out.println(socketData); sock.close(); FICHEROS: El siguiente método nunca cierra el descriptor de fichero que abre. El método finalize() del objeto ZipFile finalmente llamará al método close() pero no hay garantías de cuánto tiempo pasará antes de que el método finalize() sea invocado. En un entorno donde se produzcan muchas peticiones esto puede derivar en el agotamiento de todos los descriptores de fichero. public void printzipcontents(string fname) throws ZipException, IOException, SecurityException, IllegalStateException, NoSuchElementException { ZipFile zf = new ZipFile(fName); Enumeration<ZipEntry> e = zf.entries(); while (e.hasmoreelements()) { printfileinfo(e.nextelement()); En condiciones normales, el código siguiente cierra el handle de fichero después de imprimir todas las entradas del fichero zip. Sin embargo, si se produce una excepción durante las iteraciones, el handle de fichero no será cerrado. Si esto se produce con mucha frecuencia, la máquina virtual de java se quedará sin handles de archivo disponibles. public void printzipcontents(string fname) throws ZipException, IOException, SecurityException, IllegalStateException, NoSuchElementException { ZipFile zf = new ZipFile(fName); Enumeration<ZipEntry> e = zf.entries(); while (e.hasmoreelements()) { printfileinfo(e.nextelement()); Recomendaciones Nunca confíe en el método finalize() para liberar recursos. Para que se invoque el método finalize() de un objeto, primero el recolector de basura (garbage collector) debe determinar que dicho objeto puede ser reciclado. Puesto que el recolector de basura sólo se ejecuta cuando la máquina virtual de Java tiene poca memoria libre, no hay garantía de que el método finalize() sea invocado de manera oportuna. Una vez Página 38

40 que el recolector de basura se ejecuta, una gran cantidad de recursos son liberados en un periodo corto de tiempo lo que puede provocar una disminución temporal del rendimiento global de la aplicación. Este efecto es más pronunciado cuanto mayor sea la carga del sistema. Por otro lado, si es posible que una operación de liberación de recursos quede colgada (por ejemplo, si la finalización requiere comunicarse a través de la red con una base de datos), entonces el hilo que ejecuta el método finalize() quedará también colgado. Se recomienda liberar los recursos en un bloque finally. A continuación se detallan varios ejemplos divididos en función del tipo de recurso al que afectan. En cada uno de ellos, se indica cómo debe llevarse a cabo la implementación para garantizar que no se produzca una fuga de recursos. FLUJOS private void processfile(string fname) throws FileNotFoundException, IOException { FileInputStream fis; int sz; try { fis = new FileInputStream(fName); byte[] bytearray = new byte[block_size]; while ((sz = fis.read(bytearray))!= -1) { processbytes(bytearray, sz); finally { if (fis!= null){ safeclose(fis); public static void safeclose(fileinputstream f) { if (f!= null &&!f.isclosed()) { try { f.close(); catch (IOException e) { log(e); Esta solución utiliza una función auxiliar para registrar las excepciones que pueden originarse cuando se trata de cerrar el objeto FileInputStream. Esta función auxiliar puede ser reutilizada siempre que se quiere cerrar un objeto FileInputStream de forma segura. Página 39

41 Como puede verse, el método processfile no inicializa el objeto fis a null. En vez de ello, comprueba si el objeto fis no es null antes de llamar a safeclose(). Sin esta comprobación, el compilador de Java informa de que la variable fis puede no estar inicializada. Esta opción se aprovecha de la capacidad de Java para detectar variables no inicializadas. Si la variable fis es inicializada a null en un método más complejo, los casos en los en los que fis es usada sin ser inicializada no serán detectados por el compilador. BASE DE DATOS public void execcxnsql(connection conn) { Statement stmt; try { stmt = conn.createstatement(); ResultSet rs = stmt.executequery(cxn_sql);... finally { if (stmt!= null) { safeclose(stmt); public static void safeclose(statement stmt) { if (stmt!= null) { try { stmt.close(); catch (SQLException e) { log(e); Esta solución utiliza una función auxiliar para registrar las excepciones que pueden originarse cuando se trata de cerrar el objeto Statement. Esta función auxiliar puede ser reutilizada siempre que se quiere cerrar un objeto Statement de forma segura. También hay que notar que el método execcxnsql no inicializa el objeto stmt a null. En vez de ello, comprueba si el objeto stmt no es null antes de llamar a safeclose(). Sin esta comprobación, el compilador de Java informa de que la variable stmt puede no estar inicializada. Esta opción se aprovecha de la capacidad de Java para detectar variables no inicializadas. Si la variable stmt es inicializada a null en un método más complejo, los casos en los que stmt se utiliza sin ser inicializada no serán detectados por el compilador. Sea consciente de que cerrar una conexión a una base de datos puede o no liberar automáticamente otros recursos asociados con esa conexión. Si la aplicación utiliza un pool de conexiones, es mejor liberar explícitamente los otros recursos después de que Página 40

42 la conexión sea cerrada. Si la aplicación no utiliza pool de conexiones, los otros recursos asociados son liberados automáticamente cuando se cierra la conexión a la base de datos. En este caso, esta vulnerabilidad no es válida. SOCKETS private void echosocket(string host, int port) throws UnknownHostException, SocketException, IOException { Socket sock; BufferedReader reader; try { sock = new Socket(host, port); reader = new BufferedReader(new InputStreamReader(sock.getInputStream())); while ((String socketdata = reader.readline())!= null) { System.out.println(socketData); finally { safeclose(sock); public static void safeclose(socket s) { if (s!= null &&!s.isclosed()) { try { s.close(); catch (IOException e) { log(e); Esta solución utiliza una función auxiliar para registrar las excepciones que pueden originarse cuando se trata de cerrar el objeto Socket. Esta función auxiliar puede ser reutilizada siempre que se quiere cerrar un objeto Socket de forma segura. Se debe tener en cuenta que el método echosocket no inicializa el Socket sock a null. En vez de ello, comprueba que sock no es null antes de llamar a safeclose(). Sin esta comprobación, el compilador de Java informa de que la variable sock puede no estar inicializada. Esta opción se aprovecha de la capacidad de Java para detectar variables no inicializadas. Si la variable sock es inicializada a null en un método más complejo, los casos en los en los que sock es usada sin ser inicializada no serán detectados por el compilador. Al cerrar un socket se cierra también cualquier stream obtenido a través de getinputstream y getoutputstream. De manera inversa, cerrando cualquier stream de Página 41

43 socket se cierra el socket entero. En caso de que se tenga duda, siempre es más seguro cerrar ambos explícitamente. FICHEROS public void printzipcontents(string fname) throws ZipException, IOException, SecurityException, IllegalStateException, NoSuchElementException { ZipFile zf; try { zf = new ZipFile(fName); Enumeration<ZipEntry> e = zf.entries();... finally { if (zf!= null) { safeclose(zf); public static void safeclose(zipfile zf) { if (zf!= null) { try { zf.close(); catch (IOException e) { log(e);... Esta solución utiliza una función auxiliar para registrar las excepciones que pueden originarse cuando se trata de cerrar el fichero. Dicha función puede ser reutilizada siempre que se quiere cerrar un fichero de forma segura. También hay que notar que el método printzipcontents no inicializa el objeto zf a null. En vez de ello, comprueba si el objeto zf no es null antes de llamar a safeclose(). Sin esta comprobación, el compilador de Java informa de que la variable zf puede no estar inicializada. Esta opción se aprovecha de la capacidad de Java para detectar variables no inicializadas. Si la variable zf es inicializada a null en un método más complejo, los casos en los en los que zf es usada sin ser inicializada no serán detectados por el compilador Denegación de servicio Descripción Un atacante podría provocar que el programa se bloquee o no esté disponible para los Página 42

44 usuarios, saturando la aplicación con peticiones e incluso pudiendo especificar en estas peticiones la cantidad de recursos del sistema que se van a consumir o durante cuánto tiempo se van a utilizar. Los atacantes pueden denegar el servicio a usuarios legítimos mediante una avalancha de peticiones, pero los ataques por desbordamiento, con frecuencia, pueden ser desactivados a nivel de capa de red. Son más problemáticos los errores que permiten a los atacantes sobrecargar la aplicación usando un pequeño número de peticiones. Estos defectos permiten a los atacantes especificar la cantidad de recursos del sistema que sus peticiones consumirán o el tiempo durante el cual las usarán. Ejemplo 1: El siguiente código permite a los usuarios especificar la cantidad de tiempo durante la cual un hilo permanecerá inactivo. Especificando un número elevado, el atacante puede mantener activo el hilo indefinidamente. Por el contrario, con un número pequeño de peticiones, el atacante puede agotar el pool de hilos de la aplicación. int usrsleeptime = Integer.parseInt(usrInput); Thread.sleep(usrSleepTime); Ejemplo 2: El siguiente código lee un String de un fichero zip. Debido a que usa el método readline(), éste leerá una cantidad ilimitada de entradas. Un atacante puede hacer uso de este código para provocar una excepción, OutOfMemoryException o para consumir una gran cantidad de memoria, de forma que el programa consuma más tiempo con el recolector de basura o se queda sin memoria durante alguna operación subsecuente. InputStream zipinput = zipfile.getinputstream(zipentry); Reader zipreader = new InputStreamReader(zipInput); BufferedReader br = new BufferedReader(zipReader); String line = br.readline(); Recomendaciones Validar la entrada del usuario para asegurarse de que no realizará una utilización inapropiada de recursos. Ejemplo 1: El siguiente código permite a los usuarios especificar la cantidad de tiempo durante la cual un hilo permanecerá inactivo, pero sólo si el valor está entre límites razonables. int usrsleeptime = Integer.parseInt(usrInput); if (usrsleeptime >= SLEEP_MIN && usrsleeptime <= SLEEP_MAX){ Thread.sleepTime(usrSleepTime); else { Throw new Exception( Invalid sleep duration ); Ejemplo 2: Página 43

45 El siguiente código lee un String de un fichero zip. La longitud máxima de la cadena que leerá es MAX_STR_LEN. InputStream sipinput = zipfile.getinputstream(zipentry); Reader zipreader = new InputStreamReader(zipInput); BufferedReader br = new BufferedReader(zipReader); StringBuffer sb = new StringBuffer(); int intc; while ((intc = br.read())!= -1){ char c = (char) intc; if (c == \n ){ break; if (sb.length() >= MAX_STR_LEN){ throw new Exception( input too long ); sb.append(c); String line = sb.tostring(); 3.10 Revelación de información Violación de privacidad Descripción El manejo inadecuado de información privada, como contraseñas de usuario o números de la seguridad social, puede comprometer la privacidad del usuario y, muchas veces, es ilegal. La violación de la privacidad se da cuando: 1. Información privada de los usuarios entra en la aplicación. 2. Esta información es escrita en una localización externa, como la consola, el sistema de ficheros o la red. Ejemplo: El siguiente código contiene una sentencia de logging que realiza un registro en un fichero de log del contenido de los elementos que se han ido añadiendo a la base de datos. Entre otros valores, se almacena el valor devuelto por la función getpassword() que es la contraseña en texto plano proporcionada por el usuario y asociada a su cuenta. pass = getpassword();... dbmslog.println(id+":"+pass+":"+type+":"+tstamp); El código anterior registra una contraseña en texto plano en el sistema de ficheros. Página 44

46 Aunque muchos programadores consideran el sistema de ficheros como un repositorio seguro de datos, no se debe confiar en él implícitamente, sobre todo cuando la privacidad es un aspecto crítico. Los datos privados pueden entrar en un programa de múltiples formas: Directamente desde el usuario en forma de contraseñas o datos personales. Al ser recogida por la aplicación al acceder a bases de datos u otros repositorios de datos. Indirectamente a partir de terceras entidades. En ocasiones, datos que no son considerados como privados, pueden tener cierto impacto en la privacidad, en determinados contextos. Por ejemplo, el número de identificación de un empleado no es considerado como privado ya que no existe una forma directa y pública de mapear ese identificador con los datos personales del empleado. Sin embargo, si una empresa genera el identificador de empleado a partir de su número de la seguridad social, entonces dicho identificador debe ser considerado como privado. En ocasiones, los aspectos de seguridad y privacidad entran en conflicto. Por ejemplo, desde la perspectiva de la seguridad, todas las operaciones importantes deben ser registradas para poder posteriormente identificar cualquier actividad anómala. Sin embargo, cuando se tiene en cuenta la privacidad, esta práctica puede conllevar un riesgo. Aunque existen muchas formas en las que se puede hacer un manejo indebido de datos privados, en muchas ocasiones el riesgo aparece por poner nuestra confianza en quien no se debe. Los programadores generalmente confían en el entorno operativo donde se ejecuta la aplicación y consideran que es seguro almacenar información privada en el sistema de ficheros, en el registro, o en otros recursos controlados localmente. Sin embargo, aún si el acceso a determinados recursos está restringido, esto no garantiza que se pueda confiar en las personas que tienen acceso a dichos recursos. Por ejemplo, en 2004, un empleado sin escrúpulos de AOL vendió 92 millones de direcciones de correo electrónico de usuarios a un sitio web dedicado al spam. En respuesta a este tipo de situaciones, la recopilación y gestión de datos privados está cada vez más regulada. Dependiendo de la localización, tipo de negocio y naturaleza de los datos gestionados, una empresa u organización puede estar obligada a cumplir con diversas regulaciones (por ejemplo, en España, la Ley Orgánica de Protección de Datos o LOPD). A pesar de estas regulaciones, las violaciones de privacidad se siguen produciendo con una frecuencia alarmante. Recomendaciones Cuando la seguridad y la privacidad entran en conflicto, generalmente se debe dar mayor prioridad a la privacidad. Para cumplir con los criterios de privacidad y aún así mantener un nivel adecuado de seguridad, asegúrese de que cualquier dato privado es filtrado antes de salir del programa. Para asegurar una correcta gestión de la privacidad, el desarrollo de aplicaciones debe seguir la política y guías de privacidad internas de la organización. Estas guías deben especificar cómo una aplicación debe gestionar los datos privados. Si su organización Página 45

47 está sometida a aspectos legales relativos a la privacidad, asegúrese de que estas guías son suficientemente restrictivas como para garantizar el cumplimiento legal. Aún cuando su organización no esté afectada por aspectos legales, debe proteger la información privada o contemplar el riesgo de perder la confianza de los usuarios. La mejor política respecto a los datos privados es minimizar su exposición. Las aplicaciones, los procesos y los empleados no deben tener acceso a la información privada a no ser que sea necesario para la tarea que tienen que realizar. Al igual que el principio de mínimo privilegio dice que ninguna operación debe realizarse con más permisos de los estrictamente necesarios, el acceso a datos privados debe restringirse al grupo de usuarios más pequeño posible Fuga de información del sistema Descripción Revelar datos del sistema o información de depuración puede ayudar a un adversario a conocer el sistema y conformar un plan de ataque. Una fuga de información ocurre cuando los datos del sistema o la información de depuración salen del programa a través de un flujo de salida o función de logging. Ejemplo: El siguiente código imprime una excepción en el flujo estándar de error: try {... catch(exception e){ e.printstacktrace(); Dependiendo del sistema de configuración, esta información puede ser volcada a consola, escrita en un fichero log, o expuesta a un usuario remoto. En algunos casos, el mensaje de error dice al atacante, precisamente, a qué clase de ataque es vulnerable el sistema. Por ejemplo, un mensaje de error en base de datos puede revelar que la aplicación es vulnerable a un ataque de inyección SQL. Otros mensajes de error pueden revelar otras pistas indirectas sobre el sistema. En el ejemplo anterior, la ruta de búsqueda podría contener información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema, y el cuidado que han puesto los administradores en configurar el programa. Recomendaciones Escriba los mensajes de error pensando en la seguridad. En entornos de producción, deshabilite información detallada de error a favor de mensajes breves. Restrinja la generación y almacenamiento de salidas detalladas que puedan ayudar a los administradores y programadores a diagnosticar problemas. Tenga cuidado con las trazas de depuración, pueden aparecer en lugares no muy obvios (embebidas en comentarios en el HTML de una página de error, por ejemplo). Incluso mensajes breves de error que no revelan trazas de la pila o volcados de la base de datos pueden ayudar potencialmente a un atacante. Por ejemplo, un mensaje de Página 46

48 Acceso Denegado puede revelar que existe un fichero o usuario en el sistema. Debe escribir software que sea seguro por sí mismo, independientemente de aspectos externos como la política corporativa de IT o la audacia de los administradores de sistemas para prevenir la fuga de información del sistema Contraseñas escritas directamente en el código Descripción Las contraseñas escritas directamente en el código fuente pueden comprometer la seguridad de un sistema de una manera que puede no ser fácilmente remediable. Se suele utilizar el término hardcoded para hacer referencia a las contraseñas que están directamente escritas en el código. Nunca es una buena idea escribir directamente una contraseña en el código fuente. Esta práctica no sólo permite que la contraseña sea vista por todos los programadores involucrados en el proyecto, sino que también hace muy difícil solucionar el problema cuando es necesario. Una vez que el código está en producción, la contraseña no puede ser modificada sin liberar un parche del software. Si la cuenta protegida por la contraseña es comprometida, los responsables del sistema se verán obligados a elegir entre seguridad y disponibilidad. Ejemplo: El siguiente código utiliza una contraseña escrita directamente en el código para conectarse a una base de datos.... DriverManager.getConnection(url, "scott", "tiger");... Este código funcionará perfectamente, pero cualquiera que tenga acceso al código tendrá acceso a la contraseña. Una vez que la aplicación está desplegada, no hay forma de cambiar las credenciales para acceder a la base de datos a menos que se modifique el código del programa. Un empleado con malas intenciones y acceso a este código, puede utilizarlo para comprometer el sistema. Ni siquiera es necesario que se tenga acceso al código fuente, ya que si un atacante tiene acceso a los bytecodes de la aplicación, puede utilizar el comando javap c para desensamblar el código, que contendrá el valor de la contraseña utilizada. El resultado de esta operación puede ser algo como lo siguiente para el código visto anteriormente: javap -c ConnMngr.class 22: ldc #36; //String jdbc:mysql://ixne.com/rxsql 24: ldc #38; //String scott 26: ldc #17; //String tiger Recomendaciones Página 47

49 Las contraseñas nunca deben ser escritas directamente en el código. Es preferible que sean mantenidas en un recurso externo y ofuscadas de alguna manera. Almacenar contraseñas en texto plano en cualquier parte del sistema puede permitir a cualquier usuario con permisos suficientes leer y utilizar maliciosamente dichas contraseñas. Algunos productos hacen gala de gestionar las contraseñas de una forma más segura; por ejemplo, un servidor de aplicaciones comercial utiliza un simple XOR para ofuscar las contraseñas; sea escéptico respecto a este tipo de técnicas. Este y otros productos utilizan mecanismos de encriptación débiles o desfasados que son insuficientes para contextos en los que la seguridad es crítica. Para una solución segura, la única opción viable es una propietaria. Página 48

50 4. verificación El proceso de verificación de la seguridad de una aplicación puede dividirse en tres etapas principales: Preparación A la hora de llevar a cabo una verificación efectiva de la seguridad de una aplicación es crítico que el equipo encargado de realizar esta tarea: Entienda el propósito de la aplicación y qué puntos dentro de ella son más críticos. Identifique las principales amenazas, su motivación y cómo podrían atacar la aplicación. Para ello, antes de comenzar el proceso de verificación, el equipo deberá estar familiarizado con los siguientes aspectos: Código fuente: El equipo deberá tener conocimientos del lenguaje utilizado en la codificación y de las características de ese lenguaje desde la perspectiva de seguridad. Contexto: Se debe conocer el funcionamiento de la aplicación que está siendo revisada, el tipo de datos que se procesa y el daño que supondría que estos datos fueran comprometidos. Audiencia: Los usuarios a los que va destinada la aplicación, son Página 49