XSS desde cero (Parte II)

3. Robo de Cookies | Uso de estas.

Según Wikipedia,
Una cookie (o galleta informática) es una pequeña información enviada por un sitio web y almacenada en el navegador del usuario, de manera que el sitio web puede consultar la actividad previa del usuario.

Y una de sus principales funciones es:

Llevar el control de usuarios: cuando un usuario introduce su nombre de usuario y contraseña, se almacena una cookie para que no tenga que estar introduciéndolas para cada página del servidor.

En este taller aprenderemos a sacar las cookies de alguna persona que entre al libro de visitas, y si esa persona es el administrador, sus cookies se podrían utilizar para poder hacernos pasar por él, y entrar al panel de administración del sitio web.

Para ello, crearemos el siguiente archivo en php

cookies.php

Código: PHP
  1. <?
  2. $cookie = $_GET[‘cookie’];
  3. $fff=fopen(“cookies.txt”,”a”);
  4. fwrite($fff, “$cookie\n”);
  5. fclose($fff);
  6. ?>

Además, en el mismo path en el que estará el archivo cookies.php, debemos crear uno llamado cookies.txt vacio con permisos de escritura.

Ahora nos dirigimos a la página vulnerable y utilizaremos el siguiente vector para capturar las cookies de las personas que ingresen:

Reemplazar http://localhost/xss/cookies.php por la dirección a donde tenemos alojado el script.

Antes de crear el mensaje con la inyección, debemos recordar, que si lo introducimos, siempre que iniciemos al libro de visitas, nos redirigirá al archivo cookie.php por lo que, después de que el administrador haya entrado al sitio, deberemos de editar el mensaje, para eso, vamos a fijarnos en las urls.

 

Una vez creado, vamos a editar nuestro propio mensaje, copiando la url para después poder volver a editarlo sin entrar al index.

 

Y ahora sí, lo editamos por nuestra inyección.

Editamos el mensaje y observamos que nos ha redirigido a nuestro propio archivo.

Descartando esa cookie,ya que es la nuestra, esperaremos a que el administrador acceda al sitio.

Minutos después, comprobamos el fichero cookies.txt y observamos esto:

Sabiendo que la primera es nuestra cookie, vamos  a probar con la segunda, esperando a que sea la de un administrador.

Volvemos a nuestra url, para editar el mensaje que habíamos creado, pudiendo así acceder de nuevo al index.

Ahora, para utilizar la cookie que hemos robado, podemos usar varias extensiones, entre ellas, live http headers, tamper data, y cookie manager +, etc…

Buscamos nuestra cookie y la editamos por la que hemos conseguido:

Dejándola así:

Guardamos los cambios y refrescamos el libro de visitas.

Y bingo! Tenemos acceso a la administración.

En caso de que tengamos un XSS reflejado en algún sitio, deberemos armar toda la URL con el vector para robar la cookie, y pasarle esa url a la persona que deseemos, que por lo general suele ser a los admines de las páginas. Pero por lo general, esas urls armadas suelen ser muy evidentes, por lo que se utilizan acortadores de urls para que no sospechen.

4. Arreglando la Vulnerabilidad.

Existen varias formas de solucionar la vulnerabilidad, las más usadas es por medio de:

Conhtmlentities() todos los caracteres que tienen equivalente HTML son convertidos  y de esta forma no deja ni abrir ni cerrar etiquetas HTML. Para aplicarlo al formulario del libro de visitas, simplemente debemos modificar las líneas en donde se pasan las variables $nombre y $comentario, dejándolos de la siguiente forma:

Código: HTML5
  1.                 <div>’.htmlentities($nombre).’, publicado el ‘.$fecha.'</div>
  2.                 <div>’.htmlentities($comentario).'</div>

Una vez modificado, los scripts ya no se ejecutaran en el navegador y nos mostrara correctamente el texto ingresado.

De la misma manera,  solucionaremos la vulnerabilidad en el archivo buscador.php

 

La otra forma es con htmlspecialchars(), la cual convierte caracteres especiales en entidades HTML y realiza las siguientes conversiones:

•   ‘”‘ (comillas dobles) se convierte en ‘&quot;’ cuando ENT_NOQUOTESno está establecido.
•   “‘” (comilla simple) se convierte en ‘&#039;’ (o &apos;) sólo cuando ENT_QUOTESestá establecido.
•   ‘<‘ (menor que) se convierte en ‘&lt;’
•   ‘>’ (mayor que) se convierte en ‘&gt;’
•   ‘&’ (et) se convierte en ‘&amp;’

Suponiendo que se tiene el siguiente código vulnerable:

Código: PHP
  1. <?php
  2. $pag = $_GET[‘page’];
  3. if($pag==”index”){
  4.         echo”index”;
  5. }
  6. elseif($pag!= “”){
  7. echo”Error: “.$pag.” No existe.”;
  8. }
  9. ?>

Se aplica de la siguiente forma:

Código: PHP
  1. <?php
  2. $pag = $_GET[‘page’];
  3. if($pag==”index”){
  4.         echo”index”;
  5. }
  6. elseif($pag!= “”){
  7. $pagg=htmlspecialchars($pag, ENT_QUOTES);
  8. echo”Error: “.$pagg.” No existe.”;
  9. }
  10. ?>

Ambas son similares htmlspecialchars() convierte caracteres que se usan para trabajar con HTML (<, >, “, ‘ y &), htmlentities() traduce todos aquellos que tengan un equivalente a HTML además de los mencionados antes (Por Ejemplo: vocales acentuadas).

Leave a Comment