Normativa sobre los requisitos de Seguridad en Aplicaciones Web

Transcripción

1 Página 1 de 29 Telecomunicaciones y Sistemas Estado: Definitivo Normativa sobre los requisitos de Seguridad en Aplicaciones Web Rev. Fecha 01 16/11/2009 Versión inicial 02 02/11/2011 Actualización apartado requerimientos y recomendaciones generales 03 20/06/2012 Revisión del documento 04 15/01/2014 Actualización requisitos CAPTCHA y utilización de páginas de error personalizadas 05 31/03/2015 Actualización requisitos autenticación de aplicaciones externas a través del Sistema Clave y requisitos de seguridad en bases de datos : DGTNT TSI-NORM-SEG Normativa sobre los requisitos de Seguridad en Aplicaciones Web.odt en ecarpeta: Nivel de Seguridad: Interno Preparado por Revisado por Aprobado por Seguridad DGTNT José Damián Ferrer Quintana Roberto Moreno Díaz Fecha: 31/03/2015 Fecha: 31/03/2015 Fecha: 31/03/2015

2 Página 2 de 29 ÍNDICE 1.INTRODUCCIÓN OBJETIVO DESTINATARIOS DESARROLLO SEGURO DEL SOFTWARE REQUERIMIENTOS Y RECOMENDACIONES GENERALES AUTENTICACIÓN REQUERIMIENTOS RECOMENDACIONES AUTORIZACIÓN REQUERIMIENTOS RECOMENDACIONES GESTIÓN DE SESIONES REQUERIMIENTOS RECOMENDACIONES VALIDACIÓN DE DATOS REQUERIMIENTOS RECOMENDACIONES CONFIGURACIÓN DE LA INFRAESTRUCTURA REQUERIMIENTOS RECOMENDACIONES DENEGACIÓN DE SERVICIO REQUERIMIENTOS RECOMENDACIONES MANEJO DE ERRORES REQUERIMIENTOS RECOMENDACIONES PROTECCIÓN DE DATOS REQUERIMIENTOS RECOMENDACIONES SERVICIOS WEB REQUERIMIENTOS RECOMENDACIONES ELEMENTOS A INTRODUCIR EN EL DESARROLLO DE SOFTWARE DOCUMENTACIÓN RELACIONADA CONTACTOS... 29

3 Página 3 de INTRODUCCIÓN Las aplicaciones Web, por su arquitectura distribuida pueden ser accedidas desde cualquier ubicación, por lo que las convierte en un blanco fácil para usuarios malintencionados que aprovechan una defectuosa codificación y configuración de la aplicación para explotar todo tipo de vulnerabilidades relacionadas con la seguridad. El impacto que podría tener para el Gobierno de Canarias la explotación de determinadas vulnerabilidades sería muy perjudicial tanto para su imagen como para la confianza de los usuarios. Además de las posibles pérdidas económicas que podría ocasionar por el incumplimiento de normativas, por ejemplo de la LOPD. De este modo una adecuada codificación de la aplicación, así como una correcta configuración y fortalecimiento del sistema determina en un porcentaje muy alto la seguridad de la misma. El Gobierno de Canarias tiene publicada una normativa para la implantación de una aplicación Web sobre su infraestructura Infraestructura para las Aplicaciones del Gobierno de Canarias (CIBERC-PGS [Ref1] ). En dicho documento se citan una serie de normas y recomendaciones relacionadas con la seguridad, que deben cumplir las aplicaciones a publicar, pero esta normativa no incluye los requisitos básicos que tienen que implementarse para que el código construido sea lo más seguro posible. Este documento define los requerimientos que la Dirección General de Telecomunicaciones y Nuevas Tecnologías (DGTNT en adelante) exige a las aplicaciones Web, y que deben garantizar sus responsables, para lograr una mayor seguridad en sus aplicaciones. Los requisitos a aplicar deben proporcionar a la aplicación unos servicios de seguridad básicos como son: Autenticación de los interlocutores. Autorización o control de acceso. Confidencialidad de los datos. Integridad de los datos. No repudio. Disponibilidad de los datos. El cumplimiento de los requisitos definidos en este documento será obligatorio. La DGTNT no autorizará la publicación de una aplicación Web que no cumpla con alguna de estas condiciones. Para garantizar el cumplimiento de estos requisitos, la DGTNT tiene definido un proceso que certifica la seguridad de sus aplicaciones Web y se detalla en el documento Proceso para certificar la seguridad de las aplicaciones Web (DGTNT TSI- PRC-SEG [Ref2] ) Se implanta este proceso de conformidad con lo previsto en el Decreto 22/2008, de 19 de febrero, por el que se aprueba el Reglamento Orgánico de la Consejería de Presidencia, Justicia y Seguridad, en su artículo 74, letra ñ), es competencia de la DGTNT establecer la política de seguridad de redes, planes de contingencia, acceso a la información y de cualquier otro extremo en materia de seguridad en el área de tecnologías de la información y la comunicación.

4 Página 4 de OBJETIVO Establecer un nivel óptimo de seguridad de las aplicaciones Web publicadas bajo la infraestructura del Gobierno de Canarias. 3. DESTINATARIOS Este documento va dirigido a los responsables de las aplicaciones así como a los jefes de proyectos y equipos encargados del desarrollo y despliegue de las aplicaciones del Gobierno de Canarias. 4. DESARROLLO SEGURO DEL SOFTWARE En este apartado se definen los requerimientos que el responsable del software debe aplicar cuando se desarrolla una aplicación Web que va a ser publicada bajo la infraestructura del Gobierno de Canarias. Para una mejor descripción de los requerimientos software, se han definido 9 categorías en las que se pueden agrupar cada una de las posibles vulnerabilidades conocidas a día de hoy. Estas categorías coinciden con las definidas en la metodología de pruebas que utilizará el Gobierno de Canarias para la comprobación de estos requisitos y que está basada en OWASP [Ref3]. De esta manera se facilita la identificación de los requisitos que afectan a un caso de prueba concreto. Para cada una de estas categorías se proporcionan los requerimientos básicos y una serie de recomendaciones a cumplir. A la hora de redactar estas recomendaciones se han tenido en cuenta las tecnologías soportadas por el Gobierno de Canarias:.NET, JAVA, PHP y bases de datos (CIBERC-PGS [Ref1] ). Existen algunos requisitos y recomendaciones comunes a todas las categorías, por ello antes de comenzar con los requerimientos propios a cada grupo, se empieza con un apartado de requerimientos y recomendaciones generales Requerimientos y recomendaciones generales Toda aplicación que valide contra alguno de los repositorios corporativos deberá implementar obligatoriamente un CAPTCHA 1 con el fin de evitar el intento reiterado de acceso no autorizado. Se recomienda hacer uso del servicio CAPTCHA corporativo [REF21]. de SSO 2 corporativo, que ya integra el En caso de implementar un CAPTCHA o integrar el CAPTCHA corporativo en la pantalla de autenticación de la aplicación, deberá cumplir lo siguiente: 1 Se trata de un desafío que sólo pueda ser entendido por un humano ya que el objetivo es distinguir cuando el usuario es o no una máquina, por ejemplo la introducción de una serie de caracteres proporcionados por una imagen distorsionada que aparece en pantalla. Se utiliza para evitar ataques de fuerza bruta. 2 SSO Single Sign On o servicio de autenticación que habilita al usuario para acceder a varios sistemas con una sola instancia de identificación

5 Página 5 de 29 - La aplicación en el lado servidor, debe registrar el CAPTCHA (tanto la imagen como su ID) enviados al usuario, para la comprobación de ambos. - No implementar este control en el lado del cliente ya que se podría evadir fácilmente. - Evitar prácticas como la reutilización de tokens, el par token-solución tiene que ser válido una única vez, generándose nuevos para cada petición y destruyéndose los ya usados. - Se permite que el CAPTCHA esté inicialmente oculto y obligatoriamente se deberá mostrar tras el primer intento de acceso sin éxito. Además, en caso de implementar un CAPTCHA: - Las preguntas CAPTCHA han de ser muy numerosas, a ser posible, generadas aleatoriamente y cuyas respuestas no conformen un conjunto de datos acotados. - Para el caso de que el desafío consista en un conjunto de caracteres [REF22] : o La imagen generada ha de ser incomparable contra otras imágenes CAPTCHA capturadas. Es decir, se debe emplear un mecanismo que dificulte el reconocimiento mediante un software OCR 3. o La imagen debe combinar mayúsculas, minúsculas y números. o La imagen debe tener un cierto grado de distorsión y poca separación entre caracteres utilizando tipografía variable. o La localización de cada elemento carácter de la imagen generada ha de ser variable de forma que no permita obtener un patrón de la misma. Usar el método POST para el intercambio de información sensible entre el cliente Web y la aplicación y el método GET sólo para consultar información, de manera que nunca se envíen mediante los parámetros de una petición GET datos sensibles (usuarios, contraseñas, perfiles, identificadores de sesión, etc.). Aunque se envíen por un canal cifrado (https), las peticiones GET quedan cacheadas en el navegador, proxys intermedios, etc. pudiendo ser recuperadas. No utilizar las cabeceras HTTP como método de validación o envío de información sensible, ya que pueden ser fácilmente manipuladas por un atacante. Los precios de servicios, cambios de divisas y cualquier otra información similar, no pueden viajar del cliente al servidor, sino que tiene que estar almacenados en el servidor, para evitar manipulaciones por parte de un posible atacante. Cuando se transmitan datos confidenciales, la comunicación entre los distintos componentes del entorno Web (servidor Web, de aplicación y de bases de datos) tienen que estar cifradas y autenticadas para asegurarse su integridad. Realizar una validación de todos y cada uno de los parámetros de entrada (variables de métodos GET y POST, incluyendo campos ocultos de formularios, cookies, cabeceras). Dicha validación tiene que realizarse tanto en el cliente como en el servidor. En cliente 3 Reconocimiento óptico de caracteres

6 Página 6 de 29 para evitar enviar al servidor peticiones con parámetros mal formados. Sin embargo, filtrar los parámetros en el cliente no protege de usuarios mal intencionados, ya que es muy sencillo saltarse la validación en el cliente; así que es de obligatorio cumplimiento realizar un filtrado de datos en el servidor. Para realizar este filtrado se debe de seguir el siguiente orden: Comprobar datos obligatorios: Si se esperan en una petición determinados parámetros, comprobar que éstos son proporcionados. Y tener valores por defecto en todos los parámetros obligatorios. Longitud: Comprobar la longitud de los parámetros de entrada antes de procesarlos, el objetivo es evitar vulnerabilidades del estilo buffer overflow o DoS. Formato: Existen dos métodos para esta comprobación: Una primera opción consiste en comparar los caracteres recibidos desde el cliente con una lista de caracteres no válidos, filtrando dichos caracteres. Otra opción es permitir sólo los caracteres válidos para cada entrada en la aplicación. Se recomienda utilizar el segundo método, aunque bien es cierto que no siempre es posible por desconocimiento del conjunto de caracteres válidos. Reglas de negocio: Garantizar no sólo que los datos sean válidos, sino que cumplan con las reglas de negocio, y que estén dentro de los límites permitidos. Por ejemplo, las tasas de interés que estén dentro de los rangos permitidos. Se recomienda, siempre que sea posible, emplear desarrollos de la industria del software que sean ampliamente usados y estandarizados, pues los mecanismos a medida suelen ser más vulnerables al no estar respaldados por el uso de miles de usuarios que reportan su experiencia frente a errores conocidos. Por ejemplo, utilizar algoritmos de cifrados estándares, herramientas proporcionadas por el framework empleado como el mecanismo de gestión de sesiones del servidor de aplicaciones, etc Autenticación Se engloban en este grupo los requisitos y recomendaciones necesarios para una correcta identificación de la identidad digital del remitente de la comunicación. Existen muchas maneras de implementar un sistema de autenticación de usuarios, algunos basados en software (formulario de usuario/contraseña, certificados digitales, etc.), y otros basados en dispositivos hardware (tarjetas inteligentes, reconocimiento de huella digital, dispositivos biométricos, etc.) Nos centraremos en esta sección en los basados en software y más concretamente en el típico formulario de usuario/contraseña, por ser el más utilizado en internet. Se hace una distinción entre dos tipos de aplicaciones que requieren autenticación. Por un lado se encuentran las aplicaciones a las que accede personal relacionado con el Gobierno de Canarias, cuya autorización para acceder a la aplicación requiere un alta en el LDAP corporativo, llamémoslas aplicaciones de uso interno. Por otro lado tenemos las aplicaciones del cara al público general y las cuales puedan requerir autenticación, por ejemplo para consultar los puntos de la DGT o las multas, etc. esos usuarios ni están ni deben estar dados de alta en el LDAP corporativo, llamémoslas aplicaciones de uso externo.

7 Página 7 de Requerimientos Además de cumplir con los requisitos generales especificados en el apartado anterior, un mecanismo de autenticación basado en un formulario HTML, tiene que tener en cuenta los siguientes requerimientos: Si se trata de aplicaciones de uso interno, el proceso de autenticación se hará siempre contra el LDAP corporativo. Quedando totalmente prohibido en este caso, la gestión de bases de datos de usuarios o similar por la propia aplicación. En el documento Normativa del uso del directorio CIBERC-IGT [Ref4] se describe como hacer un uso correcto del LDAP corporativo Para las aplicaciones de uso externo, que permitan la interacción del ciudadano con el Gobierno de Canarias y basadas en la Sede Tipo, el proceso de autenticación deberá integrarse con el Sistema Clave. La gestión de usuarios desde la propia aplicación mediante una base de datos o similar solo se permitirá en el caso de que no sea posible llevarla a cabo a través del Sistema Clave mientras no esté disponible dicho sistema. La documentación de normativa técnica estará disponible en el apartado de normativas de la Web del CiberCentro. Toda operativa de usuario que requiera privilegios especiales, ha de verificar que se ha pasado previamente por un formulario de autenticación, asegurándose que éste no se pueda saltar permitiendo la navegación directa a esos recursos. Se debe definir un estricto flujo de aplicación. La transmisión de los credenciales entre el cliente y el servidor se tiene que realizar mediante un canal cifrado utilizando HTTPs, si la aplicación va sobre HTTP, hay que asegurase que se conmute a HTTPs durante el proceso de login. En el caso de las aplicaciones de uso interno, utilizar LDAPs para la comunicación entre la aplicación y el LDAP corporativo. Los credenciales nunca deben ser trasmitidos de vuelta al cliente, ni siquiera en los parámetros para una redirección o un cambio de contraseñas. El proceso de autenticación ha de partir siempre de un estado inicial AUTENTICADO = false, de manera que ante cualquier error en el proceso, el usuario no se logue en el sistema por defecto, al contrario, una excepción inesperada del sistema debería de cerrar la sesión del usuario, obligándolo a logarse de nuevo. No utilizar la etiqueta http REFERER como método de autenticación por confirmación del origen de la petición, pues esa cabecera es fácilmente modificable. No se permiten usuarios genéricos para acceder a la aplicación, cada usuario dado de alta en la aplicación debe pertenecer a una única persona. Cuando un usuario intenta logarse en el sistema: En caso de introducir credenciales de autenticación inválidas, la aplicación ha de responder con un mensaje de error genérico, del que no pueda obtenerse información acerca de que parte de la validación ha sido incorrecta, usuario o contraseña. De no ser así podrían obtenerse cuentas de usuarios válidas del sistema.

8 Página 8 de 29 Se debe establecer un número máximo de intentos con la intención de mitigar ataques de fuerza bruta. Se tienen que validar las credenciales al completo, no filtrar, truncar ni ignorar mayúsculas o minúsculas en usuarios o password para realizar la comprobación. Se tienen que registrar en un fichero de log los intentos fallidos de acceso a la aplicación, para que un administrador pueda detectar posibles intrusiones. En el caso de las aplicaciones de uso externo, cuando se permitan crean nuevos usuarios/cuentas del sistema: Con el fin de evitar la creación de cuentas automáticas, se ha de implementar CAPTCHA, o un mecanismo similar. Se deben dar indicaciones de cómo escoger una contraseña segura. Dicha contraseña debe seguir la política definida por la DGTNT (DGTNT TSI- NORM-SEG Política de contraseñas del Gobierno de Canarias [Ref5] ). No se deben permitir nombres de usuarios duplicados. Cuando el sistema genere de manera automática usuarios y/o contraseñas, éstas deben de ser lo más robustas posibles, y no deben de seguir un algoritmo de creación fácilmente predecible. Cuando las credenciales para una nueva cuenta son distribuidas, fuera de línea, éstos deberían de trasmitirse del modo más seguro posible, tener un corto periodo de validez y obligar al usuario que las modifique en el primer acceso. No utilizar password hints 4 como mecanismo para recordar la contraseña Recomendaciones Siempre es preferible usar un mecanismo de autenticación estándar proporcionado por la plataforma utilizada, que realizar uno a medida (tanto Tomcat, como JBOSS, proporcionan diversos sistemas para implementar la autenticación). Para aplicaciones de empresa basadas en JEE, se recomienda el uso de JAAS (Java Authentication and Authorization Service). Con ASP.NET, se recomienda el uso de ASP.NET Authentication Passport (conjuntamente con un servicio de Passport). Si se implementa la utilidad de Remember Me sólo debería permitir recuperar ítems no secretos, como el nombre de usuario (nunca la password). Si en una aplicación poco crítica fuera necesario recordar la password, nunca almacenarla en texto claro, debería de cifrarse con una clave que sólo la conozca el servidor. Para el caso de las aplicaciones de uso externo que gestionen su propia base de datos de usuarios, desarrollar una funcionalidad que permita cambiar la contraseña a un usuario, dicha funcionalidad tiene que estar protegida por usuario y contraseña y sólo debe permitir modificar la contraseña del usuario logado. Cuando se modifique la contraseña se debe enviar un mail informativo al usuario (a la dirección con la que se registro inicialmente) pero nunca poner información relativa al usuario o contraseña en dicho mail. Se recomienda obligar al usuario a cambiar la contraseña periódicamente. 4 Pistas en las contraseñas

9 Página 9 de 29 Para el caso en el que las aplicaciones sean de uso externo, la funcionalidad Olvidaste la contraseña : Si se desarrolla un mecanismo de preguntas secretas, etc., para restaurar la contraseña, asegurarse de que la pregunta no tenga una respuesta trivial, y protegerlo contra mecanismos de fuerza bruta. La mejor manera de restaurar la contraseña es enviar al usuario (a la dirección con la que se registró inicialmente) una URL de reactivación de cuenta (con un periodo de validez determinado y corto), con la que el usuario pueda acceder a restablecer su contraseña. En sistemas críticos se pueden utilizar autenticación con certificado de cliente, o un sistema de autenticación de múltiples factores (formulario de login, más un pin secreto, envío de sms, o incluso información basada en tokens físicos) Autorización Autorización es el concepto de permitir el acceso a determinados recursos únicamente a aquellos que tienen permiso para ello. La autorización es un proceso que llega después de una autenticación correcta Requerimientos Definir los permisos que tiene el usuario que ejecuta la aplicación con respecto a los archivos y carpetas de la máquina. Dichos permisos tienen que ser los mínimos que permitan funcionar correctamente el sistema pero que eviten acceder a recursos del servidor sobre los que no se debe tener acceso (ver requerimientos Gestión de la infraestructura apartado 4.6.). Si la aplicación trabaja con distintos perfiles, definir una lista de control de acceso a las páginas y recursos propios de la aplicación. Cuando se intenta acceder a un recurso, asegurarse que la persona que intenta acceder tiene permiso para ello y que ha realizado correctamente el proceso de autenticación, no permitiendo acceder a la funcionalidad protegida de la aplicación simplemente conociendo la URL de la petición. (Prestar especial atención al caso en que un usuario pide ver información de otra persona). Los mecanismos de control de acceso deberán estar claramente especificados en la documentación que acompaña a la aplicación para poder probar posteriormente su correcto funcionamiento en la fase de pruebas: Usuarios, perfiles, grupos, roles. Recursos accesibles desde la aplicación. Permisos de los usuarios sobre los recursos. Componentes de la aplicación que efectuarán el control de acceso. Seguimiento del flujo de información de control de acceso. Mecanismos de seguridad utilizados: usuario/pwd, SSL, etc. Cuando la aplicación acceda a otros sistemas (otras aplicaciones, bases de datos, etc.), se deben definir los permisos que requerirá un usuario de pasarela para acceder a dicho sistema, de manera que el usuario que se le proporcione a la aplicación para el

10 Página 10 de 29 acceso al tercer sistema disponga de los mínimos privilegios necesarios. Dicha información debe proporcionarse con la documentación que se adjunta de la aplicación. No basar el control de acceso en parámetros de la petición (ni campos ocultos de formulario del estilo perfil=admin), pues son fácilmente manipulables. Cuando se permita la descarga de ficheros desde la aplicación, asegurarse que no se puedan poner rutas absolutas (que sólo puedan descargarse ficheros que se encuentren en un determinado directorio por ejemplo, o enviar un índice que identificará al fichero entre los ficheros disponibles en una tabla en el servidor web). Al realizar el filtrado de los datos de entrada (requerimiento general), asegurarse de filtrar los caracteres del., /, \, y sus codificaciones (por ejemplo URL- encoded, %2e,%2f,%5c) ya que permiten navegar por el sistema de archivos. Cuando se tenga una funcionalidad cuya implementación siga un flujo basado en varios pasos, comprobar en cada paso que se ha pasado por el proceso de autenticación y autorización antes de ejecutar la acción. Si la aplicación utiliza EJBs (Enterprise Java Bean): Cualquier método de un EJB tiene que ser protegido de tal forma que sólo pueda ser invocado por usuarios legítimos que tengan el rol para ello. Si invocar un método de un EJB implica el intercambio de información sensible, se cifrará dicha información (ej: usando STO's frente a DTO's) (STO == Secured Transfer Object) Recomendaciones Utilizar el mecanismo proporcionado por el propio servidor web o servidor de aplicaciones para implementar la lista de control de acceso. Para forzar a un usuario a seguir una secuencia de páginas para ejecutar una acción, se pueden utilizar tokens de sesión por páginas (ver página 211, Per-Page Tokens, del libro The Web Application Hacker s Handbook [Ref6] ). Si la aplicación usa EJBs (Enterprise Java Bean): No se recomiendan que existan interfaces remotas en una aplicación JEE que corra sobre una máquina con una IP pública. Asociar a todos los EJB's un security-domain Gestión de sesiones El mecanismo de gestión de sesiones es igual de importante que el proceso de autenticación o autorización. Es bien sabido que el protocolo HTTP es un protocolo sin estado y que en la mayoría de las aplicaciones es necesario disponer de un mecanismo para mantener el estado de la sesión de un usuario. Se definen en este apartado los requisitos necesarios para una correcta gestión de la sesión.

11 Página 11 de Requerimientos Hay que definir un mecanismo de seguimiento de sesión, de manera que toda la información correspondiente a la sesión de un usuario concreto se encuentre almacenada en un lugar seguro del servidor, preferiblemente en memoria, indexada por el identificador de sesión. Entre el cliente y el servidor sólo se intercambiará el identificador de sesión, y nunca la información asociada a éste. No se recomienda utilizar un mecanismo de gestión de sesiones en el cliente (estilo viewstate en ASP.NET), pero si se opta por esta forma de manejar la sesión, la información enviada por el objeto que almacene los datos de sesión tiene que estar fuertemente cifrado y se debe de transmitir por un canal seguro (HTTPs). El identificador de sesión tiene que tener un mínimo de 18 cifras y debe de generarse con un algoritmo complejo de averiguar, preferiblemente con un algoritmo criptográfico conocido o ser enviado por un canal seguro (HTTPs). Cuando se asocia un nuevo identificador de sesión a un usuario, hay que asegurarse que se encuentra fuera del sistema y que ningún rol ha sido otorgado a ese identificador de sesión, hasta que se compruebe los permisos para ese usuario. Si se utiliza una cookie para el seguimiento de sesión, deben de ser establecidos los atributos de secure y de httponly, para asegurar la transferencia de dichas cookies de un modo seguro y dificultar su captura mediante código javascript. Además, en ese caso, hay que asegurarse, que cuando se requiere una acción con privilegios especiales, la url que lanza la petición, la ha generado la aplicación para el usuario logado, y no que ha sido generada por un usuario malicioso que ha engañado a dicho usuario (valiéndose de la funcionalidad innata del navegador que transmite las cookies con cada petición). Para ello, se debe incluir en la petición cierta información relacionada con la sesión, así un hacker necesitaría no sólo conocer la URL a la que quiera hacer acceder a la victima sino su identificador de sesión para poder realizar un ataque de CSRF [Ref7]. Se debe de comprobar siempre en el servidor, que el identificador de sesión recibido por la aplicación tiene un rango válido y se encuentra dentro del rango de identificadores de sesión activos y que la aplicación sepa responder ante un identificador de sesión inválido, volviendo a la página de login, para que no se produzcan comportamientos no controlados que permitan burlar el mecanismo de autorización. En las aplicaciones que requieren autenticación para su acceso, no permitir que existan dos sesiones activas a la vez para un mismo usuario logado. Si por exigencias de la aplicación esto se debe permitir (y deberá estar justificado), avisar al usuario logado cuando se ha abierto una nueva sesión con el mismo usuario. De esta manera se podría saber si otra persona está accediendo a la aplicación con su identificación. El identificador de sesión siempre tendrá un tiempo de validez limitado, y una vez la sesión caduque, el usuario deberá logarse de nuevo en el sistema. Dicho tiempo viene determinado por las siguientes situaciones: Siempre debe existir una opción en la aplicación Web que permita al usuario cerrar su sesión, y debe estar visible en todas las pantallas. De manera que cuando un usuario salga de su sesión, no sólo se cierre la ventana del navegador y se eliminen las cookies, sino que se invalide su sesión en el servidor, impidiendo la reutilización de dicho id de sesión.

12 Página 12 de 29 Cuando se cierre el navegador, o tras un periodo de inactividad no dilatado en el tiempo (no más de 15 minutos), también se debe invalidar la sesión del usuario en el servidor para evitar su reutilización, así como borrar la información almacenada en las cookies. Cuando se realizan operaciones críticas, se debe reiniciar el identificador de sesión asociado a un usuario, por ejemplo tras un proceso de login correcto, o antes de realizar una transferencia, de esta manera se pueden evitar vulnerabilidades del tipo fijación de sesión Recomendaciones Hoy en día, los servidores Web, servidores de aplicaciones y tecnologías Web proporcionan mecanismos para manejar las sesiones. Se recomienda el uso de estas implementaciones para configurar y gestionar las sesiones de los usuarios. Por ejemplo en Java utilizar la interfaz HttpSession. Se recomienda utilizar cookies no persistentes para el intercambio del identificador de sesión entre el cliente y el servidor, por ser un mecanismo transparente implementado en los navegadores y servidores web más utilizados. Como segunda opción se puede utilizar un campo oculto de formularios enviado mediante POST. Queda prohibido utilizar el mecanismo de URL Rewritting o las cookies persistentes para el transporte de dicho identificador. Algunas veces podría interesar utilizar una combinación de las técnicas descritas anteriormente para la gestión de la sesión. Cuando sea posible, comprobar que la persona que se ha logado en la aplicación, realmente es la propietaria del identificador de sesión que llega al servidor (para evitar la reutilización de sesiones). Para ello habría que almacenar en el objeto sesión el usuario que ha creado la sesión y enviar en cada petición el usuario que se ha logado (mediante la cabecera Authorization por ejemplo). Obviamente en este caso todo el tráfico debería ir por SSL para evitar el acceso a dicha cabecera. Hay que prestar especial atención a los atributos Domain y Path de las cookies de sesión, y establecerlos a los valores adecuados. Si una aplicación indica mediante el domain el dominio del directorio padre para el reenvío de las cookies, la aplicación puede ser vulnerable a ataques vía otras aplicaciones web alojadas bajo el mismo dominio padre (la cookie será enviada a una aplicación ubicada bajo ese dominio). Si el atributo path no es establecido a un valor que termine con el carácter /, el navegador enviará dicha cookie a cualquier aplicación residente en un path cuyo prefijo coincida con el especificado (ejemplo: path: /apps/ sería correcto pero si se pone /apps, se enviará por ejemplo a un directorio que sea /apps-serv/) (ver página 203, Liberal Cookie Scope, del libro The Web Application Hacker s Handbook [Ref6] ) Validación de datos Tal y como se indica en los requerimientos generales es de obligado cumplimiento realizar un filtrado de los datos de entrada. En este apartado nos centramos en los principales caracteres a

13 Página 13 de 29 tener en cuenta a la hora de realizar dicho filtrado para evitar las distintas vulnerabilidades relacionadas con una incorrecta validación de entrada de usuarios Requerimientos Para evitar el XSS [Ref8], los caracteres que tienen que filtrarse son aquellos que se utilizan para la creación de etiquetas HTML como <, >,,,(,),; y sus codificaciones (por ejemplo, <, >, %60, %62,<, >, etc.). También se deben filtrar aquellas etiquetas que tengan validez en el lenguaje html y no tengan sentido como entrada de usuario, como pueden ser: <script>, <img>, <href>, <iframe>, etc. Cuando no sea posible filtrar determinados caracteres potencialmente maliciosos, porque puedan pertenecer al conjunto de caracteres válidos, por ejemplo el carácter < (y los indicados en el punto anterior), se tiene que filtrar también la salida, los datos que devuelve el servidor al cliente, y codificar todos esos caracteres como entidades HTML (<) de manera que el navegador los interprete como texto, formando parte del contenido HTML y nunca como su estructura (código Javascript). Para evitar la inyección SQL, se tienen que utilizar consultas precompiladas con parámetros parametrizados, evitando pasar a las consultas directamente las entradas de usuarios como concatenación de String. La mayoría de las plataformas de desarrollo de aplicaciones proporcionan APIs para tal tarea (por ejemplo prepared statement en Java). En el caso de que la entrada de usuario se utilice para proporcionar el nombre de la columna de una tabla o el nombre de una tabla en cuestión, las consultas parametrizadas no evitan la posible inyección SQL; por eso se deben filtrar los siguientes caracteres propios del lenguaje SQL:, --, //, #, /*, */, ; *, %, _, +,, = ; y las siguientes sentencias SQL: OR, TRUE, SELECT, JOIN, UPDATE, INNER, INSERT, PRINT, waitfor, delay xx, etc. con sus distintas codificaciones (en hexadecimal por ejemplo). También se deben de filtrar las funciones propias de la base de datos como por ejemplo char(77) que representa la M. Para evitar inyección de comandos en otros lenguajes de consultas como LDAP o XPATH, filtrar los caracteres AND (&), OR ( ), NOT (!), <=,>=,= y ~=,*,[,]. Para evitar inyecciones de comandos del sistema operativo, filtrar el envío de caracteres especiales para el sistema operativo sobre el que corre la aplicación ( ;, >, <,, &, ` etc.). Para evitar la inyección de cabeceras y vulnerabilidades del estilo HTTP Response Expliting [Ref9], filtrar los caracteres de fin de línea, CRLF, que pueden permitir inyectar cabeceras adicionales, filtrar %0d%0a y sus posibles codificaciones. Para evitar los ataques de redireccionamiento, no permitir el paso de URLs absolutas en los parámetros de una petición (GET o POST), si fuese indispensable el paso de una URL absoluta por parámetro, comprobar que esa URL está dentro de las permitidas por la aplicación (mantener un listado de las URLs absolutas permitidas), o no enviar directamente la URL sino un número que el servidor mapee a esa URL. Debe evitarse poder cargar contenido externo y potencialmente malicioso. Para evitar ataques de polución de parámetros HTTP no permitir el carácter &.

14 Página 14 de 29 Para evitar ataques de manipulación de métodos HTTP comprobar que el método de la petición enviada corresponde a un método de los permitidos (si sólo se permiten accesos a una determinada URL mediante los métodos GET y POST, comprobar que le método recibido es de ese tipo) Recomendaciones Es posible representar los datos de entrada a una aplicación Web de múltiples formas (en ASCII, codificación de la URL, en hexadecimal, etc.). Para evitar los filtros de validación, muchos intrusos mal intencionados utilizan estos trucos. Por ello se recomienda realizar una normalización de los datos antes previa al filtrado de los mismos para convertirlos en un lenguaje común entendido por los filtros implementados. Se recomienda obligar a la aplicación a especificar un tipo de codificación en las cabeceras de respuesta, de manera que el navegador sólo interprete determinada codificación, para evitar el uso de distintas codificaciones por parte del atacante. Usar una única librería central para el filtrado de los datos, de manera que se aplique de forma homogénea los mismos mecanismos de filtrado en cualquier parte del código. Esto simplifica el mantenimiento y la actualización de los mecanismos de filtrado de toda la aplicación. Como medida de protección adicional contra el XSS, se recomienda filtrar en la salida (datos que devuelve el servidor al cliente), aquellos scripts o iframes que referencian a sitios Web remotos. Además se recomienda realizar la validación de los datos de salida siempre (no sólo cuando se han de permitir determinados caracteres, como se indicaba en los requerimientos) sustituyendo por entidades HTML cualquier carácter no alfanumérico incluido los espacios en blanco. Para prevenir el XSS basado en DOM, se recomienda realizar una validación de los datos de entrada y salida también en el cliente, ya que para desarrollar este tipo de ataques no necesariamente los parámetros introducidos por el usuario deben viajar al servidor (se puede evitar enviar el parámetro al servidor utilizando el carácter # en la URL). Se recomienda no utilizar entradas proporcionadas por el usuario directamente en el código Javascript. Tampoco se deben de emplear (entradas de usuario) en cualquier localización donde se pueden encontrar comandos Javascript directamente, por ejemplo en código HTML donde aparecen eventos que permiten cargar código javascript (<img src= datosususario o <img src= foo.gif onload= datosusuario ). En el último caso la codificación en entidades HTML no tendría efecto pues el navegador realizaría la decodificación de dichas entidades antes de procesarlas. Si una cabecera acepta entradas de usuario, se recomienda controlar el contenido de esa cabecera estrictamente, permitiendo por ejemplo sólo caracteres del abecedario y limitarlo a un ancho de por ejemplo 6 con el fin de evitar la inyección en cabeceras. Para evitar las inyecciones del sistema operativo se recomienda no utilizar los comandos propios del lenguaje de programación que permitan ejecutar órdenes del sistema operativo (por ejemplo en PHP la función exec(), o en ASP la función wscript.shell). Si es necesario ejecutar órdenes del sistema operativo con parámetros pasados por el usuario, es mejor utilizar APIs que se ejecutan proporcionando su

15 Página 15 de 29 nombre y los parámetros requeridos (y realizan el filtrado de los mismos), por ejemplo en Java, el API Runtime.exec o en ASP.NET el API Process.Start Configuración de la infraestructura Una mala configuración de la infraestructura sobre la que se despliega la aplicación permite obtener datos como puede ser el código fuente de la aplicación, acceso a interfaces administrativas, acceso a datos confidenciales, etc. Por ello es necesario especificar una serie de requisitos relacionados con la configuración que hay que cumplir cuando se implanta una aplicación Requerimientos Actualización de parches de seguridad para todos y cada uno de los elementos software que forman parte de la plataforma de la aplicación Web: software de los dispositivos de red y firewalls, sistema operativo de los servidores (Web, aplicación, y base de datos), y software de la plataforma de desarrollo empleada (PHP, ASP,Java, etc). Habilitar tan sólo los módulos del servidor que sean estrictamente necesarios para la aplicación. Se reduce de esta manera la superficie de ataque. Proporcionar con la información de la aplicación, los módulos del servidor Web o de aplicaciones, requeridos por la aplicación. En las máquinas donde corra un servicio (servidor de Aplicaciones ó motor de base de datos), se creará un usuario y un grupo exclusivo para correr el servicio y que sólo tenga los mínimos permisos necesarios sobre el sistema (por ejemplo sólo permisos en la carpeta donde esté instalado). Los servidores de aplicaciones deben correr sobre máquinas que no son públicas, situadas en subredes accesibles sólo desde máquinas de la red del Gobierno de Canarias, permitiendo únicamente conexiones desde las IPs pertenecientes a los frontales Web Externos e Internos donde se encuentran los servidores Apache. Para el caso de los servidores IIS, sólo se permitirán conexiones que provengan del proxy inverso que redirige las peticiones que llegan desde los frontales. En principio esto es así por definición (ver CIBERC-PGS , Infraestructuras para Aplicaciones del Gobierno de Canarias [Ref1] ). Eliminar cualquier funcionalidad que venga por defecto en el servidor y no sea requerida por la aplicación (como los ejemplos que vienen instalados por defecto en el Tomcat), así como todas las interfaces de gestión/administración, ya que esta funcionalidad puede contener vulnerabilidades públicamente conocidas que pongan en peligro la integridad el sistema. Deshabilitar los métodos que no requieran ser usados por la aplicación. Si sólo se requieren los métodos GET y POST, deshabilitar PUT, DELETE, TRACE, COPY, MOVE, SEARCH, PROFFIND, CONNECT en el servidor. Por tanto, se debe proporcionar con la información de la aplicación, un listado de los métodos requeridos por la aplicación, que generalmente serán GET y POST. Deshabilitar la funcionalidad de listado de directorios del servidor. Se puede configurar el servidor para servir una página por defecto cuando se intente acceder a un listado de

16 Página 16 de 29 directorios. Tener abiertos sólo los puertos requeridos para la correcta ejecución de la aplicación, no dejar puertos abiertos por defecto. Se debe incluir en la documentación que se adjunta con la aplicación el listado de puertos que utiliza la aplicación. Limpieza del sitio: en las carpetas públicas del sitio jamás se deben encontrar ficheros antiguos, copias de seguridad, archivos temporales, archivos de configuración (extensiones.bak,.tmp,.old,.conf,.cfg, etc.), y en general archivos con extensiones no reconocidas por el navegador u obsoletos. Limitar las rutas de búsqueda e indexado en el fichero robots.txt. Si no se necesitase, desactivar cualquier mecanismo de búsqueda. Cuando la aplicación contenga réplicas, asegurarse que el sitio replicado tenga exactamente el mismo contenido y configuración que el sitio original. Limitar el acceso a las interfaces de administración de los servidores de aplicaciones, servidores Web o de bases de datos, así como de cualquier otro dispositivo perteneciente a la infraestructura. Para ello: Modificar el usuario y la contraseña que viene por defecto, eliminando cualquier cuenta que no sea requerida. Sólo debe permitir conexiones desde localhost. Si no es requerida, desactivarla. Los servidores de base de datos, deben de correr sobre máquinas que no son públicas, situadas en subredes accesibles sólo desde la red interna del Gobierno de Canarias, permitiendo únicamente conexiones desde las IPs pertenecientes a las máquinas donde se encuentran los servidores de aplicaciones o los servidores Web cuando se trate de una aplicación escrita completamente en PHP, aunque no se recomienda el acceso a la base de datos desde los frontales. En principio esto es así por definición (ver CIBERC-PGS , Infraestructuras para Aplicaciones del Gobierno de Canarias [Ref1] ). Cualquier servidor web/de aplicaciones que se conecte a una base de datos, lo hará mediante un usuario distinto del usuario administrador de la propia base de datos. Se creará un usuario específico con los mínimos permisos necesarios sobre la base de datos. El demonio de base de datos sólo permitirá conexiones como administrador de base de datos desde localhost. Si se quiere acceder de manera remota, hacerlo a través de ssh con un usuario creado para tal fin. Deshabilitar la conexión mediante ssh al usuario root en la máquina donde se encuentra la base de datos, servidor de aplicaciones o el servidor web, o en general cualquier recurso que forme parte del sistema. En la mayoría de las bases de datos, vienen usuarios por defecto, muchas veces con contraseñas débiles o directamente sin contraseñas, hay que modificar esas contraseñas eliminando cualquier cuenta que no sea requerida. En las bases de datos también suelen venir definidas bases de datos de ejemplo, por ejemplo en mysql la base de datos TEST. Hay que deshabilitar o eliminar esas bases de datos.

17 Página 17 de 29 El documento CIBERC-PGS _Normativa_Corporativa_BBDD.pdf [Ref10], define una serie de normas y recomendaciones a aplicar en las bases de datos y que son complementarias a los requisitos indicados en este documento. Además, para versiones ya existentes anteriores a Oracle 10 g (incluso superiores si la configuración por defecto es modificada) la configuración de demonios de bases de datos ORACLE ha de cumplir: Se tiene que fijar la contraseña del listener para evitar que un hacker lo secuestre (aunque la contraseña pueda cambiarse editando localmente el archivo Listener.ora). Habilitar restricciones de administración para el listener (a partir de la versión 10g vienen habilitadas por defecto). Habilitar registro, sino es así, no se detectaría ningún cambio realizado al receptor, ni se auditarían posibles ataques de fuerza bruta sobre el listener. Securizar el directorio $TNS_ADMIN (generalmente $ORACLE_HOME/network/admin) para permitir acceso al fichero listener.ora sólo a la cuenta de oracle. Eliminar servicios no utilizados, como por ejemplo ExtProc Recomendaciones Se recomienda configurar el demonio de BBDD para que escuche en un puerto distinto del puerto por defecto. Lo mismo para las interfaces de administración tanto de las bases de datos, como de los servidores de aplicaciones y servidores Web. Para Oracle se recomienda securizar los ejecutables tnslsnr y lsnrctl estableciendo sobre ellos los permisos adecuados según la aplicación. Modificar los parámetros correspondientes en el servidor para evitar mostrar la versión del servidor, el sistema operativo y en general información delicada en las respuestas del servidor (cabeceras de respuestas o páginas de error) Denegación de servicio Los ataques de denegación de servicio (DoS) pueden producirse por varias causas: Inundación: se envían un gran número de peticiones, en principio legítimas, al servidor web de tal manera que éste quede colapsado por no poder atenderlas. DoS que explotan vulnerabilidades del sistema. Un atacante envía peticiones maliciosas que puede generar un bucle infinito, ralentizar gravemente la velocidad de ejecución de la aplicación, hacer que ésta deje de funcionar, provocar el reinicio de la máquina o consumir grandes cantidades de memoria. Deficiente gestión de los recursos. No cerrar convenientemente los cursores, no liberar la conexión (agotamiento del pool), por la mala codificación, mal gestión de excepciones, etc.

18 Página 18 de Requerimientos Controlar las consultas SQL limitando el número máximo de resultados (LIMIT, setmaxresult, etc.), especialmente en aquellas que utilizan comodines. Hay que evitar la sobrecarga del sistema por una consulta muy pesada (demasiado compleja en términos computacionales, un consumo excesivo de memoria por obtener demasiados resultados, etc.). Evitar el crecimiento descontrolado de una tabla de la base de datos. Controlar la creación dinámica de arrays y colecciones: El número de elementos creados en estos objetos ha de ser siempre controlado por la aplicación para evitar desbordamiento, evitando que dependa de alguna entrada de usuario, y estableciendo un límite superior. Controlar los límites de los bucles, evitando que el número de iteraciones dependa de una entrada del usuario y que dicho número de iteraciones esté controlado. Nunca ninguna condición lógica debe permitir la existencia de un bucle infinito ( while true ). Hay que revisar el código en busca de deadlocks. Esto puede hacerse mediante el uso de alguna herramienta, generalmente forman parte del IDE usado (Eclipse, Visual Studio, etc). Loggers: Control de la cantidad de información escrita en disco, especialmente loggers, evitando que éste se llene. Se ha de configurar el sistema de log limitando el tamaño de los datos escritos. Estos datos deberían ir en carpetas montadas sobre una partición dedicada. (ver la sección 4.8 Manejo de Errores ) Manejo Recursos en Modo Exclusivo: cualquier recurso que permita ser tomado en modo exclusivo (Lock) ha de ser siempre liberado. Eso hace referencia a ficheros, conexiones a bases de datos (no manejadas por contenedor) y conexiones a servidores FTP. Para asegurarse de liberar siempre el recurso incluso frente a errores inesperados, éste habrá de ser cerrado (close / release / dispose) en un bloque finally (try-catch-finally) Recomendaciones Para prevenir los ataques de inundación, se recomienda el uso de un Firewall (Stateful Firewall) que fije un límite de la tasa de conexión y rechace paquetes provenientes de IP s sospechosas. Usar un logger configurable: ver recomendaciones del apartado 4.8. (Manejo de Errores). Usar distintas particiones para alojar el sitio: usar una partición para la base de datos (si existen varios clusters de bases de datos, se recomienda montar cada uno sobre una partición distinta), otra partición para las carpetas que almacenan los logs, etc.

19 Página 19 de Manejo de errores Requerimientos Nunca se debe mostrar al usuario un mensaje de error con información de la excepción producida directamente por la aplicación. Estos errores se deben de registrar en el log de la aplicación y al usuario mostrar un error genérico que no proporcione ninguna información técnica del sistema o su arquitectura (tecnologías usadas en bases de datos, lenguajes de programación, frameworks, versiones de productos, datos de configuración del sistema, nombres de ficheros, rutas absolutas, etc.). El error mostrado tampoco contendrá información confidencial ni dará pistas sobre ella (por ejemplo en un proceso de login incorrecto no indicar si se ha introducido mal el usuario o la contraseña). Se tiene que realizar un correcto manejo de excepciones, capturando todas las posibles excepciones incluyendo aquellas cuya captura no es obligada (RuntimeException en Java o System.* Exception en.net). Se tienen que registrar los eventos producidos por la aplicación en un fichero de log que permita reconstruir la historia de una sesión de navegación a través de la aplicación. Este fichero es muy útil para resolución de problemas, auditorías, respuesta ante incidentes y análisis forense. Hay que definir qué acciones van a generar eventos de logs y con qué nivel de detalle (info, debug,etc.). Centralizar la función de logueo en una librería del servidor, de forma que se disponga de un mecanismo único y consistente de logueo para el conjunto global de la aplicación (por ejemplo log4java para Java, log4net para.net y log4php para PHP). Pues hay que tener en cuenta que según la normativa definida en el documento Infraestructuras de Aplicaciones del Gobierno de Canarias, CIBERC-PGS [Ref1] no se permite la escritura de ficheros directamente desde la aplicación. El fichero de log deberá incluir la siguiente información: Fecha y hora. Servicio invocado. En aplicaciones Web, típicamente la URL. Identificador de usuario. Parámetros de entrada (nombres de ficheros, etc). La aplicación deberá generar trazas en el fichero de log, de los siguientes eventos: Arranque, inicialización y parada de la aplicación. Intentos de acceso tanto con éxito como no permitidos Invocación de programas. En el caso de aplicaciones Web se deberán registran las llamadas a servlets, EJB s, JSP s. El fichero de log debe estar ubicado en una ruta privada del sitio, y a ser posible, montada sobre una partición distinta del resto del sistema. Además se debe controlar el tamaño máximo de los datos escritos en estos archivos, la rotación de los mismos y configurar correctamente los permisos de acceso a dicho fichero, pues sólo tienen que poder ser accedidos por el administrador de la aplicación para una operación de lectura y por el usuario que ejecuta la aplicación para una operación de escritura.

20 Página 20 de 29 Nunca se deben usar mensajes de depuración mediante comandos que muestren el mensaje por consola (print, echo, out, etc.). Todos estos mensajes han de ser eliminados del código o sustituidos por un comando del logger usado (log.debug, log.error, etc.) antes de subir la aplicación a producción. Utilizar las páginas de error corporativas para la gestión de errores del servidor de aplicaciones (por ejemplo la página de HTTP 404 not found, HTTP 500, etc.), tal como se indica en la normativa definida en el documento Infraestructuras de Aplicaciones del Gobierno de Canarias, CIBERC-PGS [Ref1] Recomendaciones Crear nuestras propias excepciones de aplicación para gestionar los errores. Se pueden limitar estas excepciones así como sus mensajes a un número pequeño de situaciones, fácilmente controlables, que puedan ser propagadas hasta el usuario final sin darle detalles confidenciales del sistema. Registrar los errores de la aplicación y los de lógica de negocio en distintos archivos. Registrar intentos de intrusión de usuarios no autorizados, (errores en el proceso de login), así como la detección de parámetros contaminados (inyecciones de código, inyecciones SQL, etc.). Estos sucesos pueden ser escritos en un fichero de log dedicado. Además, si la aplicación (o el módulo de la aplicación) que detecta la intrusión es crítico, el sistema debe redirigir la petición a la página de registro/login. Podría también enviarse automáticamente un mail al administrador indicándole de posibles intentos de intrusión. Existen sistemas de detección de intrusos de libre distribución que pueden ser utilizados, por ejemplo OSSEC [Ref11] Protección de datos Se establecen tres categorías de confidencialidad para los datos, que se utilizarán en la redacción de los requerimientos y recomendaciones: a) Datos muy sensibles que no pueden bajo ningún concepto almacenarse en texto claro, pero que el sistema necesita registrar de alguna manera, por ejemplo el número de la tarjeta de crédito de un cliente, o contraseñas de usuarios. b) Datos que no son extremadamente sensibles pero que no se desean almacenar en texto claro para que no los pueda conocer ni siquiera el administrador del sistema, por ejemplo los sueldos de los empleados. Además, se incluyen en esta categoría los datos de carácter personal de nivel alto ya que aunque la normativa en materia de protección de datos no obliga a cifrarlos, es recomendable. Ejemplo: informes médicos. c) Datos cuyo almacenamiento puede y debe realizarse en texto plano, por ejemplo el listado de comunidades autónomas, provincias y ciudades, códigos postales de España, tablas con datos fijos del sistema, etc