Segurinfo NOA Seguridad en el desarrollo de aplicaciones Web

Transcripción

1 Segurinfo NOA 2011 Seguridad en el desarrollo de aplicaciones Web Hernán Santiso Gerente de Seguridad de la Información Claro Argentina, Uruguay y Paraguay hsantiso@claro.com.ar

2 Introducción El problema del software inseguro es quizás el reto técnico más importante de nuestros tiempos. La seguridad es ahora uno de los factores claves limitantes sobre los que podemos crear con la tecnología de la información. El aumento de la concientización de seguridad ha hecho que muchas organizaciones implementen controles de seguridad de red y sistemas operativos en forma cada vez más eficientes. Como contrapartida los atacantes han migrado los ataques hacia las aplicaciones, que en su mayoría son basadas en web

3 Seguridad en el Ciclo de Desarrollo de Software (SDLC) Para prevenir problemas de seguridad recurrentes en una aplicación, es esencial el construir la seguridad dentro del Ciclo de Vida de Desarrollo del Software (SDLC), desarrollando estándares, políticas y guías de uso que encajen y funcionen dentro de la metodología de desarrollo. El SDLC es un proceso bien conocido por los desarrolladores. Mediante la integración de la seguridad en cada fase del SDLC, permite una aproximación integral a la seguridad de aplicaciones que se apoya en los procedimientos ya existentes en la organización. Si bien los nombres de las varias fases pueden cambiar dependiendo del modelo SDLC usado por una organización, cada fase conceptual del arquetipo SDLC será usada para desarrollar la aplicación (es decir, definir, diseñar, desarrollar, implementar, mantener). Cada fase tiene implicaciones de seguridad que deberán formar parte del proceso existente, para asegurar un programa de seguridad rentable y exhaustivo.

4 Cuanto antes mejor El detectar un bug en una etapa temprana dentro del SDLC permite que pueda ser abordado con mayor rapidez y a un coste menor. Un bug de seguridad no es diferente de uno funcional o de un bug en el rendimiento, en este contexto. A pesar de que las nuevas bibliotecas, herramientas o lenguajes pueden ayudar a diseñar mejores programas (con menos bugs de seguridad), nuevas amenazas están apareciendo constantemente y los desarrolladores deben ser conscientes de aquellas que afectan al software que están desarrollando. La educación en seguridad ayuda también a los desarrolladores a adquirir el enfoque apropiado para probar una aplicación desde la perspectiva de un atacante. Esto permite a cada organización considerar los problemas de seguridad como una parte de sus responsabilidades.

5 Costo de la Seguridad en el SDLC Tiempo

6 Que es OWASP? Open Web Application Application Security Project Promueve el desarrollo de software seguro Orientada a la prestación de servicios orientados a la Web Se centra principalmente en el "back-end" mas que en cuestiones de diseño web Un foro abierto para el debate Un recurso gratuito para cualquier equipo de desarrollo de software

7 Qué nos brinda OWASP Materiales de Educación OWASP SAMM OWASP Top 10 Guía de Desarrollo OWASP Guía de Testing OWASP Guía OWASP para aplicaciones Web Seguras Software WebGoat WebScarab ESAPI Capítulos Locales Comunidades interesadas en Seguridad de Aplicaciones

8 OWASP - SAMM El modelo de madurez para el aseguramiento de software (SAMM por sus siglas en inglés) es un marco de trabajo abierto para ayudar a las organizaciones a formular e implementar una estrategia de seguridad para Software que sea adecuada a las necesidades específicas que está enfrentado la organización. Los recursos que provee SAMM nos ayudan a: Evaluar las prácticas de seguridad en Software existentes en la organización Construir un programa de seguridad en Software balanceado en iteraciones bien definidas Demostrar mejoras concretas en el programa de aseguramiento de Software Definir y medir las actividades relacionadas con seguridad en la organización

9 SAMM

10 SAMM Gobierno Gestión global de las actividades de desarrollo de software Estrategia y métricas : Dirección estratégica global del programa de aseguramiento de software e instrumentación de procesos y actividades para recolectar métricas acerca de la postura de seguridad de una organización. Política y cumplimiento : Involucra establecer una estructura de control y auditoria para seguridad y cumplimiento de regulaciones a lo largo de una organización para alcanzar un aseguramiento superior en software bajo construcción y en operación. Educación y orientación : Involucra incrementar el conocimiento de seguridad entre el personal de desarrollo de software a través de entrenamiento y orientación en temas de seguridad pertinentes a funciones del trabajo individual.

11 SAMM Construcción Definición de metas y creación de software dentro de proyectos de desarrollo Evaluación de amenazas : Identificar y caracterizar con precisión los ataques potenciales contra el software de una organización, con el fin de comprender mejor los riesgos y facilitar su gestión. Requisitos de seguridad : Promover la inclusión de las necesidades de seguridad durante el proceso de desarrollo de software a fin de especificar la funcionalidad correcta desde el principio. Arquitectura de seguridad : Fortalecer del proceso de diseño con actividades para promover diseños con seguridad en mente y los marcos de trabajo en que se basa el software.

12 SAMM Verificación Verificación y prueba de componentes producidos a través del desarrollo de Software Revisión de diseño : Inspección de artefactos creados a partir del proceso de diseño para asegurar la provisión de mecanismos de seguridad adecuados y apegados a las expectativas de seguridad de la organización Revisión de código : Evaluación del código fuente de una organización para ayudar en el descubrimiento de vulnerabilidades y actividades relacionadas a la mitigación como es el establecimiento de bases para las expectativas de la seguridad en programación. Pruebas de seguridad : Probar el software de la organización en su ambiente de ejecución para descubrir vulnerabilidades y establecer un estándar mínimo para la liberación del software.

13 SAMM Implementación Administración de la liberación de sistemas que han sido creados Administración de vulnerabilidades : Establecer procesos consistentes para administrar reportes internos o externos de vulnerabilidades para limitar la exposición, recopilar datos y así mejorar el programa de aseguramiento. Fortalecimiento de ambientes : Implementación de controles para el ambiente operativo que rodea a los programas de una organización para reforzar la postura de seguridad de las aplicaciones que han sido implementadas. Habilitación operativa : Identificar y capturar información relevante a la seguridad que necesita un operador para configurar, instalar y correr los programas de una organización.

14 SAMM - Niveles de Madurez Cada una de las prácticas de seguridad tiene tres niveles de madurez bien definidos y un nivel inicial (cero) implícito. Los detalles de cada nivel difieren entre las prácticas pero generalmente representan: 0) Punto de inicio implícito, las actividades en la practica no se han realizado 1) Entendimiento inicial y provisión ad hoc de la práctica de seguridad 2) Incremento en la eficiencia y/o efectividad de la práctica de seguridad 3) Dominio amplio de la práctica de seguridad

15 Fallas de Seguridad en aplicaciones Web

16 OWASP Top Ten (2010 Edition)

17 A1 Inyection Las fallas de inyección, tales como SQL, OS, y LDAP, ocurren cuando datos no confiables son enviados a un interprete como parte de un comando o consulta. Los datos maliciosos del atacante pueden engañar al interprete en ejecutar comandos no intencionados o acceder datos no autorizados. Una falla de este tipo puede provocar una pérdida o corrupción de datos, falta de integridad, o denegación de acceso y hasta algunas veces permitir la toma de posesión completa del servidor o la base de datos comprometida

18 A2 Cross Site Scripting (XSS) Un ataque de Cross-Site Scripting consiste en una inclusión de un script en una página Web que se ejecuta cuando la página es accedida por un usuario Estas fallas ocurren debido a que las aplicaciones toma datos no confiables y los envía al navegador web sin una validación y codificación apropiada. Esto permite a los atacantes ejecutar secuencia de comandos en el navegador de la victima los cuales pueden secuestrar las sesiones de usuario, destruir sitios web, o dirigir al usuario hacia un sitio malicioso.

19 A2 Cross Site Scripting (XSS) TIPOS DE XSS 1) No permanente o Reflejado El código de scripting se incluye en el request, generalmente en la URL 2) Permanente El código de scripting se almacena en la capa de persistencia de la aplicación (Base de datos o Archivos) 3) Local Por alguna otra debilidad el atacante logra inyectar el código de scripting en un archivo almacenado localmente en el equipo de la víctima

20 A3 Fallos de Autenticación y Manejo de Sesión Por la naturaleza del protocolo HTTP que no es orientado a conexión, se hace necesario implementar mecanismos de manejo de sesión entre el cliente y el servidor que si no son implementados correctamente pueden ser alterados para obtener acceso no autorizado a los recursos. Las funciones de la aplicación relacionadas a autenticación y gestión de sesiones son frecuentemente implementadas incorrectamente, permitiendo a los atacantes comprometer contraseñas, claves, o id de sesiones, o explotar otras fallas de implementación para asumir la identidad de otros usuarios.

21 A3 Fallos de Autenticación y Métodos de ataque: Manejo de Sesión Predicción de sesiones Generalmente cuando se puede predecir un ID de sesión Permite crear un ID de sesión válido de otro usuario Reutilización de sesiones Cuando un ID de sesión caducó se reutiliza en poco tiempo Fijación de sesiones Cuando se puede generar un ID de sesión arbitrario desde el el cliente Sniffing de identificadores de sesión Si el canal no está encriptado Si el ID de sesión está en la URL

22 A4 Referencia Directa a Objetos insegura Una referencia directa a objetos ocurre cuando un desarrollador expone una referencia a un objeto de implementación interno, tal como un archivo, directorio, o base de datos sin un chequeo de control de acceso u otra protección, los atacantes pueden manipular estas referencias para acceder datos no autorizados. Cuando se realiza una referencia directa a objetos internos y no se valida la correspondencia del usuario logueado con el valor referenciado, se corre el riesgo de ver datos de otro usuario Ejemplo con acceso a una cuenta bancaria: El usuario podría modificar el número de cuenta en la URL Lo mismo puede pasar con un archivo:

23 A5 Cross Site Request Forgery (CSRF) Un ataque CSRF obliga al navegador de una victima autenticada a enviar una petición HTTP falsa, incluyendo la sesión del usuario y cualquier otra información de autenticación incluida automáticamente, a una aplicación web vulnerable. Esto permite al atacante forzar al navegador de la victima para generar pedidos que la aplicación vulnerable piensa son peticiones legítimas provenientes de la victima. Esta vulnerabilidad es causada porque los browsers incluyen automaticamente las credenciales de autenticación (ID de sesión, IP Address, Credenciales de dominio, etc.) en cada request.

24 A5 Cross Site Request Forgery (CSRF) Ejemplo: La aplicación permite que los usuarios envíen peticiones de cambio de estado que no incluye seguridad El atacante construye una petición que transfiera dinero desde la cuenta de la víctima a su propia cuenta e inserta la misma dentro de una etiqueta de imagen en un sitio web que esté bajo su control y al que la víctima se podrá dirigir. <imgsrc=" Account=attackersAcct# width="0" height="0" /> Cuando la víctima visite el sitio, en lugar de cargarse la imagen, se realizará la petición HTTP alterada. Si la víctima previamente había adquirido privilegios sobre el sitio original entonces el ataque será exitoso.

25 A6 Configuración Defectuosa de seguridad Una buena estrategia de seguridad requiere tener definida e implementada una configuración segura para la aplicación, framework, servidor de aplicación, servidor web, base de datos y plataforma. Todas estas configuraciones deben ser definidas, implementadas, y mantenidas ya que por lo general no son seguras por defecto. Esto incluye mantener todo el software actualizado, incluidas las librerías de código utilizadas por la aplicación. Ejemplos de configuración insegura: Cuentas por defecto Páginas de ejemplo en desuso Consola de administración activas y accesibles Falta de actualización de patches Seteos de configuración por defecto Claves de encripción débiles.

26 A7 Almacenamiento Criptográfico Inseguro Muchas aplicaciones web no protegen adecuadamente los datos sensibles, tales como tarjetas de crédito, datos personales y credenciales de autenticación con mecanismos de cifrado o hashing. Los atacantes pueden modificar o robar tales datos protegidos inadecuadamente para realizar robos de identidad, fraudes de tarjeta de crédito u otros delitos. Esta vulnerabilidad normalmente compromete todos los datos que deberían haber estado cifrados. Ejemplos: Falta de cifrado de datos sensibles Claves de cifrado débiles Algoritmos inseguros o mal implementados Manejo y almacenamiento inseguro de las claves de cifrado

27 A8 -Falla de Restricción de Acceso a URL Algunas aplicaciones web verifican los privilegios de acceso a URLs antes de generar enlaces o botones protegidos. Sin embargo, las aplicaciones necesitan realizar controles similares cada vez que estas páginas son accedidas por fuera del circuito normal, de lo contrario los atacantes podrán alterar las URLs para acceder a estas páginas igualmente, simplemente forzando el acceso a la URL objetivo. Este tipo de vulnerabilidades se encuentran con frecuencia cuando links y botones simplemente se ocultan a usuario no autorizados, pero la aplicación no protege adecuadamente las páginas de destino.

28 Ejemplo: A8 -Falla de Restricción de Acceso a URL Considere las siguientes URLs las cuales se supone que requieren autenticación. Y para acceder a la página admin_getappinfo se necesitan permisos de administrador Si la aplicación es vulnerable, un usuario autorizado pero que no sea Administrador puede acceder a la página admin_getappinfo a través de la invocación a la URL.

29 A9 Protección Insuficiente en la capa de Transporte Las aplicaciones frecuentemente fallan al autenticar, cifrar, y proteger la confidencialidad e integridad de tráfico de red sensible. Cuando esto ocurre, es debido a la utilización de algoritmos débiles, certificados expirados, inválidos, o sencillamente no utilizados correctamente.

30 A9 Protección Insuficiente en la Ejemplos : capa de Transporte Autenticación sin SSL : El atacante captura el tráfico de red y observa la cookie de sesión de una víctima autenticada. Certificado SSL configurado incorrectamente : Provoca que el navegador muestre advertencias que los usuarios tienen que aceptar para poder acceder, y por lo tanto se acostumbren a estos avisos. Un ataque de phishing que redirija a los clientes a otra aplicación similar que no dispone de un certificado válido, y como estos están acostumbradas a dichas advertencias no notan la diferencia. Trafico hacia las bases de Datos sin encriptar: Una aplicación simplemente utiliza ODBC/JDBC para la conexión con la base de datos, sin darse cuenta de que todo el tráfico se transmite en claro.

31 A10 - Redirecciones y reenvíos no validados Las aplicaciones web frecuentemente redirigen y reenvían a los usuarios hacia otras páginas o sitios web, y utilizan datos no confiables para determinar la página de destino. Sin una validación apropiada, los atacantes pueden redirigir a las víctimas hacia sitios de phishing o malware, o utilizar reenvíos para acceder páginas no autorizadas.

32 A10 - Redirecciones y reenvíos Ejemplos : no validados 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 el phishing e instala código malicioso La aplicación utiliza un parámetro para indicar dónde será dirigido el usuario luego de determinada transacción. En este caso, el atacante compone una URL que evadirá el control de acceso de la aplicación y llevará al atacante a una función de administración a la que en una situación habitual no debería tener acceso:

33 Buenas prácticas de seguridad para el desarrollo de aplicaciones Web Validación de ingreso de entrada Autenticación y Autorización Manejo de sesión Criptografía Manejo de Errores y logs de auditoría Configuración

34 Validación de Entrada La falta de validación de ingreso de datos es la fuente de la mayoría de las vulnerabilidades en aplicaciones. Nunca se debe confiar en los datos que el usuario final ingresa. Se recomienda implementar una estrategia basada en capas donde se verifique: Chequeos de integridad Validaciones Reglas de Negocio Utilizar en la medida de lo posible Validación Positiva y Alinear la exhaustividad de los controles con análisis de riesgo.

35 Estrategias de validación Aceptar sólo los buenos conocidos. (Validación positiva) Los siguientes parámetros deberían incluirse en una validación positiva: Tipo de datos (cadena, entero, real, etc. ) Largo mínimo y máximo Si se aceptan o no nulos. Si existen parámetros que son requeridos. Rango númérico. Expresiones regulares. Rechazar los malos conocidos (Validación negativa)

36 Autenticación - Buenas Prácticas Implementar un proceso de administración de usuarios. Alinear las credenciales con el valor de los activos. Contraseñas Certificados digitales Tokens Biometría Reautenticar cuando se requiere accesos a mayores privilegios. Proteger las transacciones No implemente credenciales de autenticación del lado del cliente

37 Contraseñas - Buenas Prácticas Utilice políticas de contraseñas (fortaleza, almacenamiento, control de cambio y uso) Utilice transporte seguro (SSL) Implemente cuidadosamente las funcionalidades que permiten rehabilitar una contraseña ante olvidos. Elimine los nombres de usuario por defecto Utilice HTTP headers y tags para prevenir el caché de contraseñas. Implemente hash para contraseñas.

38 Autenticación fuerte Tener en cuenta que las contraseñas pueden ser vulneradas con distintas metodologías. Considere la alternativa de implementar autenticación fuerte cuando el riesgo lo justifique. Métodos de autenticación fuerte: One-time passwords Certificados digitales Sistemas desafío respuesta Tarjeta de Coordinadas Biometría Firma digital de transacciones

39 Autorización - Buenas Prácticas Respete el principio de Mínimo privilegio Implemente rutinas de autorización centralizadas Utilice Matrices de autorización Priorice la protección de los activos más críticos. Ser cuidadoso con los controles de autorización a medida. Separar en las aplicaciones los accesos de administrador y usuario final.

40 Manejo de Sesión HTTP no es orientado a conexión Las credenciales de usuario se envían a través de los requerimientos HTTP Las tecnologías de páginas dinámicas (J2EE, PHP, ASP.NET) se embeben dentro de HTTP. Se utilizan Cookies para obtener datos de sesión del cliente.

41 Manejo de Sesión - Buenas prácticas Almacene la información de sesión del lado del servidor Implemente tiempo de vida para las sesiones Provea opciones de desconexión (logout) Revalide credenciales Luego de un log-on / log-off Después de un determinado tiempo Detecte bloqueos y loguee ataques fuerza bruta. Utilice HTTPS

42 Criptografía - Buenas prácticas No confunda encripción con codificación Use algoritmos conocidos, no escriba los suyos propios. Analize cuidadosamente el algoritmo a utilizar y el largo de claves. Diseñe su aplicación de manera que puede incorporar nuevos algoritmos. Proteja y administre las claves de encripción

43 Manejo de errores - Buenas prácticas Defina una estructura para manejo de errores de excepción. Implemente rastreo de eventos desde dentro de la aplicación. Envíe mensajes generales a los usuarios finales No habilite modo debug en producción Falle seguro, no debe archivos abiertos. No almacene información de rastreo o relacionada con la privacidad de las personas

44 Logs de Auditoría - Buenas Prácticas Verifique requerimientos legales y defina los requerimientos de auditoría en base a ellos. Sólo audite los eventos más importantes Centralice los logs Mantenga los logs seguros y confidenciales y realice respaldo de los mismos Trabaje siempre sobre una copia de sólo lectura para generar reportes y búsquedas en los logs.

45 Configuración - Buenas Prácticas Elimine todas las configuraciones por defecto que sean innecesarias No utilice cuentas por defecto No implemente puertas traseras No almacene passwords en claro en los archivos de configuración. Utilice protocolos de transferencia segura (SSL / SSH) Mantenga el sistema operativo y software de soporte actualizado.

46 Preguntas