PDF de programación - XSS - Vulnerabilidad estudiada a fondo

Cross Site Scripting

Por Trew



La vulnerabilidad estudiada a Fondo



Puedes distribuir este texto libremente siempre y cuando no sea

modificado.



25-02-2007



“Maybe you can’t break the system,

But you can always hack it.”



http://www.icenetx.net
http://trew.icenetx.net



Contacto:

[email protected]



“Una vulnerabilidad es tan limitada como tu quieras que sea”

=============
Introducción:
=============

Cualquiera puede encontrar una gran cantidad de textos y manuales que
traten sobre Cross Site Scripting. El problema es que la mayoría de
esos textos no explican a fondo este tema. Mi objetivo con este texto
es que el lector entienda a fondo este tipo de vulnerabilidad, que
conozca y descubra varios métodos de ataque, y sepa como protegerse
contra el Cross Site Scripting.

Para poder comprender este manual en su totalidad, el usuario debe de
saber un poco de HTML, y de ser posible algo de JavaScript.

El Cross Site Scripting (XSS) es una vulnerabilidad muy común hoy en
día, se puede encontrar en la mayoría de las aplicaciones web en
Internet.
Mucha gente ve el XSS como una vulnerabilidad obsoleta, y con este
manual voy a demostrar que si se sabe como explotar, puede ser de gran
provecho. No por ser un fallo muy común deja de ser importante.

Este fallo compromete más que nada, la seguridad del usuario y no la
del servidor. Consiste en inyectar código HTML o Javascript en una
aplicación web, con el fin de que el navegador de un usuario ejecute el
código inyectado al momento de ver la página alterada.
Comúnmente el XSS se utiliza para causar una acción indebida en el
navegador de un usuario, pero dependiendo de la vulnerabilidad, puedes
explotar el fallo para causar una acción indebida en un servidor o en
una aplicación.

Esta limitación se debe a que el código HTML se interpreta en el
navegador de un usuario y no en el servidor. Así que si alguien inyecta
código HTML en alguna aplicación web no podría hacer daño alguno al
servidor, ya que éste nunca interpreta el código HTML, solo los
navegadores. Por eso este ataque se determina: “ataque del lado del
cliente”.

El XSS se puede utilizar para hacer phishing, robo de credenciales,
troyanizar navegadores, o simplemente para hacer un deface. Todo
depende de la página.



====================
¿Cómo sucede el XSS?
====================

Con este manual me iré desde lo más básico. En muchos textos de XSS que
he visto dicen algo como:
“Ve a algún formulario de búsqueda de una web y pon:
<script>alert();</script>, si sale una ventanita es vulnerable…”
Y entonces quien lee el manual, y no tiene idea de XSS, no entiende
porque sucede ésto, y nunca podrá poder saltarse un filtro de XSS, y
jamás podrá inyectar código fuera de un formulario. Explicaré la
vulnerabilidad de modo que se entienda a fondo el por qué de ésta.

Lo primero que se debe lograr al querer explotar alguna aplicación con
XSS, es inyectar código HTML a la web; es decir, lograr incluir HTML
escrito por nosotros en el código fuente de la página.

Analizaremos el método más sencillo y popular: el del formulario de
búsqueda xD.
Tomemos como ejemplo: http://www.pan.senado.gob.mx
Si vamos a la página, podemos ver en la parte izquierda superior,
debajo del logo del pan, un pequeño campo de texto que dice “Búsqueda”.
Este es el campo vulnerable a inyección HTML.
A continuación, ponemos en el campo de búsqueda “rastan” xD, y le damos
clic en buscar, esperamos a que se cargue la página y podemos observar
el texto:


Resultados de buscar: rastan

No se encontraron resultados de Resultados de buscar: rastan



(¿No se encontraron resultados DE RESULTADOS? xD…)


Analizando este resultado (de resultado xD) podemos ver que la página
probablemente es vulnerable a XSS. ¿Por qué? Miremos el código fuente:

<tr>
<td width="100%" height="99%" class="TituloPag">
Resultados de buscar: rastan </td>
</tr>

La cadena ‘rastan’, que nosotros le dimos al servidor, es incluida en
el código fuente de la página, mmm.. ¿y si le damos alguna otra cadena
al servidor? ¿Qué tal si intentamos algo como: <h1>pricka</h1>?
Probemos…



En el navegador:

En el código fuente:

Resultados de buscar:

pricka

<tr>
<td width="100%" … >
Resultados de buscar: <h1>pricka</h1></td>
</td </tr>


Genial, es vulnerable. El código que escribimos en el campo de búsqueda
se incluyo en el código fuente de la página como si fuera parte de
ésta, y nuestro navegador interpretó el código. Esto es Cross Site
Scripting.

Otro modo de inyectar el código sería darle el valor de búsqueda a
través de la URL:

http://www.pan.senado.gob.mx/resultados.php?txttexto=hola

En conclusión: la vulnerabilidad de XSS ocurre cuando la página permite
al usuario incluir código en la página. ¿De qué nos sirve? Ahora
veremos varios tipos de bugs, métodos de inyección y tipos de ataque.



=========================
Tipos de vulnerabilidades
=========================

Existen 3 tipos conocidos de Vulnerabilidades XSS.

• El tipo-0, que se utiliza para ejecutar código remotamente con los

permisos de otro usuario.

• El tipo-1, ataque no-persistente o reflejado (explicado más

adelante) utilizado en páginas no estáticas.

• Y el tipo-2, ataque persistente, donde se inyecta código en

páginas estáticas.

Estos tipos de vulnerabilidades son en los que se basan todos los demás
ataques. Es importante que el lector analice estos tres tipos de
ataques para identificar en que áreas son peligrosos, que se puede
lograr con ellos, y como prevenirlos.



Tipo-0

Esta vulnerabilidad es conocida como: “DOM-Based cross-site-scripting”
o “cross-site-scripting local”.
Es un ataque poco usual y talvez algo complicado de explicar. No
trataré esta vulnerabilidad a fondo, pero este manual hace un buen
trabajo explicándola: http://www.webappsec.org/projects/articles/071105.shtml

La diferencia entre el tipo-0 y los otros tipos de ataque, es que el
código se inyecta a través de la URL pero no se incluye en el código
fuente de la página. Es decir, el código nunca llegó a la página, solo
se ejecutó en el navegador.
Esto nos podría servir de modo que, le demos una URL maligna a alguna
víctima que tenga alguna página hospedada en su máquina y, cuando la
víctima le da la URL a su navegador el código se ejecuta en su
navegador, dicho código podría realizar alguna acción en la página
hospedada por la víctima, y como fue ejecutado en el navegador de la
víctima también se ejecuta con los permisos que tiene la víctima en su
máquina. Esto podría llevar a realizar alguna acción remotamente en la
página de la víctima, como si este usuario las hubiera realizado.

De una forma a grandes rasgos: el tipo-0 ejecuta código remotamente en
la máquina de un usuario con los permisos de este usuario.

Veamos un ejemplo de esta vulnerabilidad. Imaginemos que la siguiente
página (www.vulnerable.com/index.html) tiene el siguiente código:

(NOTA: el siguiente ejemplo fue sacado del artículo enlazado

anteriormente)

<HTML>
<TITLE>Bienvenido!</TITLE>
Hola
<SCRIPT>
var pos=document.URL.indexOf("nombre=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
Bienvenido a nuestra página
…
</HTML>

La página anterior se utilizaría para darle la bienvenida a algún
usuario por su nombre, ejemplo:
http://vulnerable.com/index.html?nombre=piupert
Esto mostraría algo como: “Hola piupert Bienvenido a nuestra página”

De cualquier modo, una petición del siguiente modo:
http://vulnerable.com/index.html?nombre=<script>alert();</script>
Daría resultado a un XSS. Veamos por qué:

El navegador de la víctima visita el enlace, hace una petición HTTP a
vulnerable.com y recibe la página index.html. Después el navegador
empieza a interpretar el HTML de la página y forma la estructura del

documento. El documento contiene un objeto llamado ‘document’, que
contiene una propiedad llamada ‘URL’, y esta propiedad es remplazada
por la URL de la página actual, como parte de la estructura del
documento. Cuando el intérprete llega al código Javascript lo ejecuta y
modifica el HTML en bruto. En este caso, el código hace referencia a
‘document.URL’, y entonces, esta cadena es incluida en el HTML al
momento de interpretar el código, después es inmediatamente
interpretada y ejecutada en el contexto de la misma página, por lo
tanto la condición XSS.

Nota:
La inyección maligna nunca fue incluida en el HTML en bruto
(en cambio a los otros tipos de XSS).
Este ataque solo funciona si el navegador no modifica los
parámetros de la URL. (Ejemplo: ‘<’  ‘%3C’).

En el ejemplo anterior todavía se puede discutir que la inyección si
llegó al servidor (en el ‘?nombre=’ de la petición HTTP), y por lo
tanto puede ser detectado como cualquier ataque XSS. Pero aún así esto
podemos arreglarlo. Consideren el siguiente ataque:

http://vulnerable.com/index.html#name=<script>alert();</script>

La almohadilla (#) le dice al navegador que todo lo que va después de
ella es un fragmento, y no parte de la petición. Los navegadores no
mandan los fragmentos al servidor, así que el servidor solamente vería:
http://vulnerable.com/index.html, logrando que ni el servidor vea la
inyección, esta técnica de eva