Ataques Aplicaciones WEB

1. Ataques Aplicaciones WEB • Lucía Castro • Víctor Cabezas • Diana Checa

2. Introducción: ¿Quiénes y por qué atacan a las aplicaciones web?

3. ¿Qué motiva a un cracker? • Notoriedad: El conocimiento que un cracker acumula es una forma de poder y prestigio • Reto intelectual: Necesitan demostrar que posee una capacidad intelectual superior. • Aburrimiento: Hallar una victima es a veces el resultado de no haberla buscado específicamente en un sitio en particular. • Venganza: No es una buena política tener a uno de estos señores como enemigo. • Dinero: La motivación de siempre. • Profesión: Tanto ilegal como legalmente se ha convertido en una profesión altamente rentable.

4. Porqué atacan a las aplicaciones web De igual manera que el hacker tiene motivaciones específicas, hay ciertas características que refuerzan la motivación de ataque: • Técnicas relativamente simples de ataque • Anonimato • Ubicuidad • Incapacidad de detección de los firewalls de redes. • Código personalizado (home made) con alto nivel de fallas • Procesos de seguridad inmaduros • Cambio constante, alto nivel de dinamismo • … y por supuesto dinero.

5. Anatomía de un ataque a una aplicación web

6. ¿Qué es OASP? El Open Web Application Security Project es una organización sin fines de lucro fundada con el propósito de divulgar, detectar y crear métodos de corrección para las amenazas que aquejan a las aplicaciones web en general. OWASP tiene capítulos alrededor del mundo:

7. Top Ten Most Critical Web Application Vulnerabilities – 2010 Inyección de código o de comandos. • SQL injectionSucede al insertar comandos de SQL a través de parámetros no desinfectados, en cadenas utilizadas para consultas dinámicas. h • OS commandinjectionSucede al insertar caracteres especiales de secuencia (“&&” en Windows y “;” en Linux) para introducir comandos adicionales en cadenas que solicitarán ejecución de comandos de sistema operativo. • LDAP injectionEs parecida al SQL injection y se utiliza para introducir comandos LDAP en consultas a este tipo de servicio. • XPATH injectionParecida también al SQL injection pero con el fin de construir consultas XPATH para archivos XML

8. Top Ten Most Critical Web Application Vulnerabilities – 2010 Inyección de código o de comandos.

9. Top Ten Most Critical Web Application Vulnerabilities Cross Site Scripting – XSS (3) Las fallas de XSS suceden cuando una aplicación toma datos no validados ni desinfectados y los envía al navegador sin la propia validación o códigos de escape. El XSS permite a los atacantes ejecutar scripts en el navegador de la victima que pueden secuestrar su sesión, modificar sitios web o redirigir al usuario a sitios web dañinos.  Esta técnica suele ser una de las más utilizadas en la actualidad para engañar a los usuarios. En combinación con el phishing y el pharming suele ser extremadamente peligrosa. Existen varios tipos de XSS, pero sin duda todos ellos son altamente peligrosos.

10. Top Ten Most Critical Web Application Vulnerabilities – 2010 Cross Site Scripting – XSS Existen tres tipos de XSS conocidos: Directo o reflejado Es aquel que utiliza un campo o dato introducido por un usuario en un formulario para introducir código javascript que se refleja de inmediato en el proceso siguiente o resultante. Almacenado o latente Es aquel que introduce el código javascript en un campo de base de datos o en un cookie que puede ser mostrado en cualquier ocasión que se solicite el dato comprometido. DOM XSS o del tercer tipo Es el menos común y más complejo de realizar y depende de la utilización del URL en código javascript por parte del programador

11. Top Ten Most Critical Web Application Vulnerabilities – 2010 Cross Site Scripting – XSS

12. Top Ten Most Critical Web Application Vulnerabilities – 2010 Cross Site Scripting – XSS

13. Top Ten Most Critical Web Application Vulnerabilities – 2010 Cross Site Scripting – XSS

14. Top Ten Most Critical Web Application Vulnerabilities – 2010 Autentificación rota y manejo de sesión mal implementado Las funciones relacionadas con la autentificación y el control de sesión muchas veces no son implementadas correctamente, permitiendo a los atacantes comprometer claves de acceso, llaves de control y “tokens” de sesión, permitiéndoles asumir las identidades de las victimas. Se estima que en la actualidad una aplicación de banca en línea segura debe manejar entre 4 a 5 factores de autentificación de los cuales uno de ellos debe permitir que el usuario verifique la validez de la aplicación y otro debe ser externo a la misma.

15. Top Ten Most Critical Web Application Vulnerabilities – 2010 Autentificación rota y manejo de sesión mal implementado

16. Top Ten Most Critical Web Application Vulnerabilities – 2010 Autentificación rota y manejo de sesión mal implementado • ¿Es su aplicación vulnerable a este tipo de vulnerabilidades? • ¿Están las credenciales del usuario protegidas usando “hashing” o cifrado? • ¿Pueden las credenciales ser “adivinadas” o sobre escritas debido a manejo de las funciones de cuenta débiles? (ej. creación de cuentas, cambio de password, recuperación de password, Id de sesión débil). • ¿Están los IDs de sesión expuestos en el URL? • ¿Son los IDs de sesión vulnerables a ataques de fijación de sesión? • ¿Puede el usuario hacer logout cuando sale del sistema? • ¿Su aplicación implementa timeout? • ¿Implementa su aplicación algún control de ToL (Time of Life) • ¿Se rotan los IDs de sesión una vies que el usuario hace Login exitosamente? • ¿Envía los passwords solamente a través de TSL o SSL?

17. Top Ten Most Critical Web Application Vulnerabilities – 2010 Autentificación rota y manejo de sesión mal implementado Posibles soluciones (1): • Implemente una política de password fuerte como por ejemplo: • Un largo de mínimo de 8 caracteres. • Al menos un caracter en mayúsculas (A-Z). • Al menos un dígito (0-9). • Al menos un carácter especial (@#%&!). • No acepte más de 3 caracteres idénticos seguidos (111, eee). • No acepte secuencias simples de teclado (qwerty, asdfgh, zxcvb). • Las soluciones javascript no son apropiadas a nivel de validación de input, pero un control indicador de la fuerza de la clave al momento de crearla puede ser de gran ayuda. En este caso usted debe decidir si recibir o no la clave proporcionada con una segunda validación del lado del servidor.

18. Top Ten Most Critical Web Application Vulnerabilities – 2010 Autentificación rota y manejo de sesión mal implementado Posibles soluciones (2): • Maneje adecuadamente las respuestas de error de acceso. • Respuestas indebidas: • “Acceso no autorizado: clave de usuario errónea" • “Acceso no autorizado: Identificador de usuario inválido” • “Acceso no autorizado: Cuenta de usuario bloqueada" • “Acceso no autorizado: Este usuario no está activo” • Cualquier otra respuesta que muestre al atacante que ha fallado en el procedimiento de ingreso. • Respuesta correcta: • “Acceso no autorizado: Los datos proporcionados no son válidos”

19. Top Ten Most Critical Web Application Vulnerabilities – 2010 Cross Site Request Forgery (CRSF). Un Ataque de CRSF también conocido como XSRF, fuerza al usuario/navegador "logueado y validado" de la victima a mandar un “HTTP request“ forjado, a una aplicación web vulnerable a este tipo de ataque. Esto permite al atacante forzar al navegador de la victima para acometer daños o estafas que la aplicación atribuye a un usuario legítimo. Quizás esta es una de las vulnerabilidades llamada a ser la más importante en los próximos años. Se le conoce como el gigante dormido del OWASP top 10

20. Top Ten Most Critical Web Application Vulnerabilities – 2010 Cross Site Request Forgery (CRSF).

21. Muchas gracias por su atención…