(In)Seguridad en la Web

Presentación del tema: "(In)Seguridad en la Web"— Transcripción de la presentación:

1 (In)Seguridad en la Web
OWASP Top

2 ¿Qué es OWASP? Open Web Application Security Project
Organización sin fines de lucro enfocada en mejorar la seguridad en el desarrollo de software Materiales y recursos bajo licencia  open source y gratuitos Cientos de proyectos relacionados para análisis y verificación de seguridad en el software OWASP Zed Attack Proxy OWASP Web Testing Environment Project OWASP ModSecurity Core Rule Set Project OWASP CSRFGuard Project OWASP Enterprise Application Security Project

3 OWASP Top Ten (2013 Edition) Los 10 riesgos de seguridad más críticos en aplicaciones Web
A1: Inyección A2: Quiebre de autenticación y administración de la sesión A3: Cross-Site Scripting (XSS) A4: Referencia directa a objeto inseguro A5: Mala configuración de Seguridad A6: Exposición de datos sensibles A7: Inexistente control de acceso a nivel de función A8: Falsificación de Solicitud de sitio cruzado (CSRF) A9: Usar componentes vulnerables A10: Reenvíos y redirecciones no validadas A9 is the only new item in the top 10 for 2013.

4 A1 - Inyección Inyección significa… Intérpretes…
Engañar a una aplicación incluyendo comandos en los datos enviados a un intérprete. Inyección significa… Toman strings y los interpretan como comandos SQL, OS Shell, LDAP, XPath, Hibernate, etc… Intérpretes… Muchas aplicaciones se mantienen susceptibles. Aún cuando no es muy difícil evitarla. SQL injection es bastante común Usualmente severo. La base de datos completa puede ser vista o modificada. Incluso puede permitir acceso al esquema completo de la base de datos, acceso a cuentas o acceso a nivel de sistema operativo. Impacto típico

5 Ilustración de Inyección de SQL
HTTP request• SQL query• Account Summary Acct: Acct: Acct: Acct: Account: SKU: Account: SKU: HTTP response  ✇ DB Table  ✇ "SELECT * FROM accounts WHERE acct=‘’ OR 1=1--’" Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions Application Layer Databases Legacy Systems Web Services Directories Human Resrcs Billing APPLICATION ATTACK Custom Code La aplicación presenta un formulario al atacante. El atacante escribe datos en el formulario La aplicación envía el ataque a la base de datos en una query SQL. La base de datos ejecuta la consulta que contiene el ataque y envía el resultado a la aplicación. La aplicación prepara los datos de manera normal y los envía al atacante. App Server Web Server Hardened OS Network Layer Firewall Firewall

6 Impedir fallas de inyección
Evitar el intérprete completamente Usar una interfaz que soporte variables de binding (por ejemplo sentencias preparadas o procedimientos almacenados) Las variables de binding permiten al intérprete distinguir entre código y datos. Codificar todas las entradas de usuario antes de entregárselas al intérprete. Siempre efectuar validación de los datos de usuario, respecto de lo autorizado a ingresar. Siempre minimizar privilegios de base de datos para reducir el impacto de los errores de seguridad. Recomendaciones Para mayores detalles Referencias Bind variables are «substituion» variables that are used in place of literals select * from empleado where empno=1234 select * from empleado where empno=:x

7 A2- Quiebre de la autenticación y administración de sesión
Significa que las credenciales deben entregarse en cada request. Debiera usar SSL para cada requerimiento de autenticación. HTTP es un protocolo sin estado Se usa SESSION ID para controlar el estado dado que HTTP no puede. Y es tan bueno como entregar las credenciales a un atacante. SESSION ID normalmente es expuesta en la red, en el browser, en los logs. Fallas de manejo de sesión Cambiar la password, recordarla, olvido de contraseña, pregunta secreta, dirección de correo electrónico. Cuidado con las puertas laterales Cuentas de usuario comprometidas o sesiones secuestradas Impacto típico

8 Ilustración de quiebre de autenticación
1 El usuario envía credenciales Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions El sitio usa reescritura de URL (Por ej. Escribe el ID de la sesión en la URL) 2 3 El usuario hace clic al link en un foro. El hacker observa los registros en Y encuentra el JSESSIONID del usuario. 4 5 El hacker usa el JSESSIONID y toma el control de la cuenta de la víctima.

9 Evitar el Quiebre de la autenticación y administración de sesión.
La autenticación debe ser simple, centralizada y estandarizada. Usar el session ID provisto por su contenedor. Asegurarse que SSL protege las credenciales y el session ID en todo momento. Verifique su arquitectura Veridicar su certificado digital Examinar todas las funciones relacionadas con la autenticación Verificar que el logoff realmente destruye la sesión Use WebScarab o ZAP de OWASP para probar la implementación Verificar la implementación Siga las indicaciones desde:

10 A3 – Cross-Site Scripting (XSS)
Los datos maliciosos de un atacante se envían al browser de un usuario inocente. Ocurre en cualquier momento Almacenados en la base de datos Reflejados desde la entrada (campo de formulario, campo oculto, Url) Enviados directamente vía JavaScript Datos maliciosos… Intente en su browser dogitando: javascript:alert(document.cookie) Virtualmente toda aplicación web tiene este problema Robo de la sesión de usuario, robo de datos sensibles, reescritura de la página web, redirección del usuario a un sitio maligno. Instalar proxies XSS que permiten al atacante observar y dirigir todo el comportamiento de un usuario en un sitio vulnerable y forzar que el usuario acceda a otros sitios. Impacto típico Los ataques XSS son un tipo de inyección, en la cual se inyectan scripts maliciosos en sitios web. Los ataques XSS ocurren cuando un atacante usa una aplicación web para enviar código malicioso, generalmente en la forma de un script a ejecutar en el browser a un usuario final. Las fallas permiten que estos ataques sucedan y son bastante comunes y ocurren en cualquier en cualquier lugar donde la aplicación web usa entradas del usuario dentro de la salida que genera sin validarla o codificarla. Un atacante puede usar XSS para enviar un script malicioso a un usuario. El browser del usuario no tiene manera de saber que el script podría no ser confiable y lo ejecutará. Dado que piensa que el script proviene de una fuente confiable, el script malicioso puede acceder a cualquier cookie, tokens de sesión o cualquier otra información sensible retenida por el browser y usada con ese sitio. Estos scripts pueden incluso reescribir el contenido de una página HTML.

11 Ilustración de XSS 1 El atacante pone la trampa: “Actualizar mi perfil” trap – update my profile Aplicación con vulnerabilidad XSS almacenada EL atacante ingresa un script malicioso en una página web que almacena datos en el servidor Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions 2 La víctima visita la página e ingresa la información. El script se ejecuta en el browser de la víctima con total acceso a la información que éste maneja 3 El script silenciosamente envía al atacante las cookies de sesión de la víctima

12 Impedir fallas XSS Recomendaciones Referencias Eliminar la falla
No incluír datos entregados por el usuario en la página de salida Defenderse contra la falla Usar políticas de seguridad de contenido Recomendación primaria: Codificar la salida de toda la información ingresada por el usuario.(Usar OWASP ESAPI o codificadores Java para codificar la salida) Crear una lista blanca de validación en todas las entradas que sean incluídas en la página Para grandes cantidades de código HTML entregado por el usuario, utilizar AntiSamy de OWASP para sanitizar ese HTML y hacerlo seguro. Referencias Para cómo codificar código de salida apropiadamente, leer: Site Scripting) Prevention Cheat Sheet

13 A4 – Referencia directa a objeto
Exigir autorización apropiada (falla al restringir acceso a URL) ¿Cómo proteger el acceso a los datos? Sólo listar los objetos autorizados para el usuario Esconder las referencias a objetos en campos ocultos No implementar esas restricciones en el lado del servidor El atacante se “salta” ese control de acceso de capa de presentación ingresando parámetros en la URL Error común… Los usuarios pueden acceder a archivos o datos no autorizados. Impacto típico

14 Ilustración de Referencia directa a objeto
El atacante se percata que el parámetro de su cuenta es 6065 ?acct=6065 Lo modifica a un número cercano: ?acct=6066 Ahora el atacante tiene acceso a la información de la cuenta de la víctima.

15 Evitar la referencia directa a objeto
Eliminar la referencia directa a un objeto Reemplácelas con un valor de asignación temporal (ej. 1, 2, 3) OWASP ESAPI entrega soporte para asignaciones numéricas y aleatorias Validar la referencia directa a un objeto Verifique el valor del parámetro está correctamente formateado Verifique que el usuario tiene acceso al objeto Restricciones de SQL query (constraints) Verifique que el modo de acceso está permitido sobre el objeto (lectura, escritura, eliminación) Access Reference Map Report123.xls Acct:

16 A5 – Fallas en la Configuración de Seguridad
Desde el SO hasta el servidor de aplicaciones Las aplicaciones Web descansan en la seguridad Piense en todos los lugares a los que su código fuente viaja La seguridad no debiera requerir código fuente secreto ¿Su código fuente es secreto? Todas las credenciales deben cambiarse en producción La administración de credenciales debiera extenderse a todas las partes de la aplicación Instalación de backdoor aprovechando vulnerabilidades no parchadas en el servidor Acceso no autorizado a cuentas por defecto, funcionalidad de aplicaciones o datos Impacto típico

17 Ilustración de Fallas en la Configuración de Seguridad
Database Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions Custom Code App Configuration Development Framework App Server QA Servers Web Server Hardened OS Insider Test Servers Source Control

18 Evitar Fallas en la Configuración de Seguridad
Verifique la administración de la configuración Seguir guías de endurecimiento de la configuración Debe cubrir la plataforma y la aplicación Analizar efectos que produce en la seguridad Verificar la implementación Buscar configuraciones genéricas y problemas de parches no instalados

19 A6 – Exposición de datos sensibles
Fallas al identificar datos sensibles Fallas al identificar todos los lugares en los que se almacenan los datos sensibles Bases de datos, archivos, directories, logs, respaldos Fallas al identificar los lugares a los que se envían los datos senibles A la web, a otras bases de datos, a socios de negocios, comunicaciones internas Fallas al proteger apropiadamente estos datos en cada ubicación Almacenar y trasnmitir datos sin seguridad Los atacantes acceden o modifican información confidencial o privada Tarjetas de crédito, fichas personales, datos financieros Los atacantes extraen secretos para usar en ataques adicionales. Pérdida de confianza en la compañia, insatisfacción del consumidor Gastos en corregir el inicdente, gastos en seguros El negocio es multado Impacto típico (Insecure Cryptographic Storage & insecure channel protection)

20 Ilustración de almacenamiento de datos inseguro
La víctima ingresa su número de tarjeta de crédito en un formulario 1 Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions Log files 4 Un atacante interno roba 4 millones de números de tarjetas de crédito 2 El manejador de errors registra los números de tarjetas de crédito en el log, porque no hay comunicación con el Sistema 3 Los logs son accesibles a todos los miembros de IT para debug

21 Evitar el almacenamiento inseguro
Verifique su arquitectura Identifique todos los datos sensibles Identifique todos los lugares donde se almacenan los datos Use encriptación para contrarrestar las amenazas Protegerse con mecanismos apropiados Encriptación de datos, encriptación de la base de datos, encriptación de los elementos de datos Usar los mecanismos correctamente Usar algoritmos robustos Generar, distribuir y proteger claves apropiadamente Estar preparados para cambio de claves Verificar la implementación ¿Se usa un algoritmo estándar y robusto? ¿Es el apropiado? ¿Todas las claves, certificados y passwords están correctamente almacenados y protegidos? ¿Tiene lugar una distribución segura de claves y un efectivo plan para cambio de éstas? Analizar código de encriptación para detectar fallas

22 Ilustración de protección insuficiente de la capa de transporte
Socios de negocio Víctima externa Custom Code Backend Systems Empleados 2 1 Atacante interno roba credenciales de acceso y datos fuera de la red Atacante interno roba credenciales de acceso y datos desde la red interna Atacante externo Atacante interno

23 Evitar protección insuficiente de la capa de transporte
Protegerse con mecanismos adecuados Usar TLS en todas las conexiones con datos sensibles Usar HSTS (HTTP Strict Transport Security) Usar key pinning (browser “marca” certificado de servidor para verificación futura) Encriptar mensajes antes de transmitirlos XML-Encryption Firmar mensajes antes de transmitirlos XML-Signature Usar los mecanismos correctamente Usar algoritmos estándar y robustos Manejar adecuadamente claves y certificados digitales Verificar certificados SSL antes de usarlos Ver para más detalles.

24 A7 – Control de acceso a nivel de función inexistente
Obligando a una efectiva “Autorización” ¿Cómo protéger el acceso a las URLs (páginas)? ¿O a las funciones referidas por una URL más parámetros? Mostrar sólo links y opciones de menú autorizadas El control de acceso a nivel de capa de aplicación no funciona El atacante logrará tener aceso directo a páginas no autorizadas. Un error común Los atacantes invocan funciones y servicios a los que no están autorizados Acceso a otras cuentas de usuarios y datos Efectuar acciones con privilegios sobre el sistema Impacto típico

25 Ilustración de Control de acceso a nivel de función inexistente
El atacante se da cuenta que la URL indica su rol /user/getAccounts Modifica la URL para accede a otro directorio (rol) /admin/getAccounts, ó /manager/getAccounts El atacante accede a más cuentas que las que su propio rol

26 Evitar Control de acceso a nivel de función inexistente
Por función, un sitio necesita hacer 3 cosas: Restringir acceso a usuarios autenticados (si no es público) Aplicar permisos basados en usuarios o roles (si es privado) No permitir requerimientos a tipos de páginas no autorizados (ej. archivos de configuración, logs, archivos fuente) Verificar su arquitectura Usar un modelo simple en cada capa Asegúrese que realmente tienen un mecanismo de control de acceso en cada capa Verifique la implementación Verifique que cada URL (además de los parámetros) referencian a una función que es protegida por: Un filtro externo, como JavaEEweb.xml Verificaciones internas en el código (ej. usar método de ESAPI isAuthorizedForURL()) Verificar que la configuración de servidor desactiva requerimientos a tipos de archivos no autorizados. Usar OWASP ZAP para detectar acceso a páginas o archivos no autorizadas

27 A8 – Solicitud de falsificación a través de sitios (CSRF)
Un ataque donde se engaña al browser de la víctima hacia una aplicación web vulnerable. La Vulnerabilidad es causada porque los browser almacenan y escriben automáticamente datos de autenticación de l usuario (Session ID, IP, Credenciales de login) con cada request. Cross Site Request Forgery Iniciar transacciones (transferir dinero, cerrar cuenta, cerrar sesión) Acceso a datos sensibles Cambiar información de cuentas Impacto típico Un ataque CSRF forza a una víctima, con credenciales almacenadas en el browser, a enviar un request HTTP, incluyendo la cookie de sesión y cualquier otra información de autenticación automáticamente incluída, a una aplicación web vulnerable. Esto permite al atacante forzar que el browser de la víctima genere requests que la aplicación vulnerable piensa que son legítimos.

28 CSRF Patrón de vulnerabilidad
El problema Los navegadores automáticamente incluyen credenciales en cada requerimiento. Incluso para requerimientos causados por un formulario, script o imagen en otro sitio web. Todos los sitios que descansan solamente en credenciales automáticas son vulnerables. Entrega automática de credenciales Cookie de sesión Header de autenticación básica Dirección IP Certificados SSL del lado del cliente Autenticación de dominio de Windows

29 Ilustración CSRF El Atacante pone la trampa en un sitio web o la envía por 1 Etiqueta <img> oculta que contiene un ataque contra el sitio vulnerable Aplicación con vulnerabilidad CSRF Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions Mientras inicia sesión en el sitio vulnerables, la víctima ve el sitio del atacante. 2 3 La etiqueta <img> cargada por el browser envía un request GET (incluyendo credenciales) al sitio vulnerable. El sitio vulnerable ve un request desde la víctima y efectúa la acción solicitada.

30 Evitar fallas CSRF Agregue un token secreto a todos los requests sensibles (no debe ser automáticamente enviado) Hace imposible que el atacante modifique el requerimiento Los tokens debieran ser robustos criptográficamente Opciones Almacenar un token en la sesión y agregarlo a todos los formularios y links Campo oculto: <input name="token" value="687965fdfaew87agrde" type="hidden"/> URL: /accounts/687965fdfaew87agrde Token en el formulario: /accounts?auth=687965fdfaew87agrde … Se puede usar un token por cada función Usar un hash del nombre de la función, session id y la password Puede requerir autenticación secundaria para funciones sensibles No permitir que los atacantes almacenen código malicioso en su sitio web Codificar todas las entradas antes de enviar los datos Esto hace que todos los links y solicitudes sean inertes ante el intérprete Para mayores detalles revisar:

31 Todos usan bibliotecas vulnerables
29 MILLION vulnerable downloads in 2011 Libraries 31 Library Versions 1,261 Organizations 61,807 Downloads 113,939,358 This is why A9 was added to the OWASP Top 10 in Everyone uses vulnerable libraries and we need to get processes and tools in place to significantly reduce their use!!

32 A9 – Usar componentes vulnerables
Algunos componentes vulnerables pueden ser identificados y explotados con herramientas automatizadas Los componentes vulnerables son comunes Virtualmente cada aplicación tiene estos problemas En muchos casos, los desarrolladores ni siquiera conocen todos los componentes que usan Expansión Completo rango de debilidades Impacta completamente el sistema Impacto típico

33 ¿Qué se puede hacer para evitarlo?
Verificaciones automáticas periódicamente Que le informe las vulnerabilidades conocidas Ideal Chequeo periódico manual y upgrade consecuente Si alguna está desactualizada, pero no quiere actualizar, verificar si existen problemas de seguridad para esa biblioteca Mínimo Verificar bases de datos de vulnerabilidades como CVE. Actualizar si corresponde También podría ser

34 A10 – Redirecciones y reenvíos no validados
Y frecuentemente usan parámetros entregados por el usuario en la URL destino. Si no son validados, el atacante puede enviar a la víctima a un sitio de su preferencia. Las redirecciones de aplicaciones web son muy comunes Internamente envían los request a una nueva página en la misma aplicación A veces los parámetros los define la página destino Si no son validados, un atacante puede usarlo para saltar verificaciones de autenticación. Los reenvíos también son comunes (Transferencia en .NET) Redirigir a la víctima a un sitio phishing o malicioso El requerimiento del atacante es reenviado para pasar por alto verificaciones de seguridad, permitiendo funciones no autorizadas o acceso a datos restringidos Impacto típico

35 Ilustración de redirección no validada
1 Se envía el ataque vía o por página web From: Internal Revenue Service Subject: Your Unclaimed Tax Refund Our records show you have an unclaimed federal tax refund. Please click here to initiate your claim. 3 La aplicación redirecciona a la víctima al sitio del atacante Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions La víctima selecciona el link que contiene parámetros no validados 2 El request se envía a un sitio vulnerable, incluyendo el sitio destino del atacante como parámetro. La redirección envía a la víctima al sitio del atacante. Evil Site El sitio malicioso instala malware en la víctima o extrae información privada por phishing 4 … &dest=

36 Ilustración de reenvío no validado
1 El atacante envía un ataque a la página vulnerable a la cual tiene acceso El request se envía a una página vulnerable a la cual el usuario tiene acceso. La redirección envía al usuario directamente a la página privada, saltándose el control de acceso public void sensitiveMethod( HttpServletRequest request, HttpServletResponse response) { try { // Do sensitive stuff here. ... } catch ( ... 2 La aplicación autoriza el request la cual continúa a la página vulnerable Filtro 3 La página reenviada falla en validar el parámetro, enviando el atacante a una página no autorizada, saltándose el control de acceso. public void doPost( HttpServletRequest request, HttpServletResponse response) { try { String target = request.getParameter( "dest" ) ); ... request.getRequestDispatcher( target ).forward(request, response); } catch ( ...

37 Evitar Redirecciones y reenvíos no validados
Evitar usar redirecciones y reenvíos Si se usan, no involucrar parámetros de usuario en la definición de la URL destino Si debe incluír parámetros de usuario: Valide cada parámetro para asegurarse que es válido y autorizado Use asignación del lado del servidor para traducir la opción provista al usuario con la página actual. Defensa en profundidad: Para redirecciones, valide la URL destino después que sea determinada y asegúrese que dirige a un sitio externo autorizado ESAPI lo puede hacer por usted Ver: SecurityWrapperResponse.sendRedirect( URL ) SecurityWrapperResponse.html#sendRedirect(java.lang.String) Algunas ideas acerca de proteger reenvíos Idealmente, debiería llamar el controlador de acceso para asegurarse que el usuario está autorizado antes de que usted efectúe el reenvío. Con un filtro externo, como Siteminder, no es muy práctico. Lo mejor es asegurarse que los usuarios que pueden acceder la página original están autorizados a acceder a la página destino.

38 Resumen. ¿Cómo lidiar con estos problemas?
Desarrollar código seguro Seguir las mejores prácticas en la guía para construir aplicaciones Web seguras de OWASP Y las hojas de apuntes: Use el estándar de verificación de seguridad de aplicaciones de OWASP para asegurar una aplicación Use componentes estándar de seguridad que calzan con su organización Use ESAPI OWASP como base para sus componentes estándar Revise sus aplicaciones Tenga un team de expertos para revisar sus aplicaciones Revise usted mismo sus aplicaciones siguiendo las guías de OWASP Guía de revisión de código de OWASP: Guía de pruebas de OWASP:

39 Gracias OWASP Top