Mostrar Mensajes
A primera instancia muchos dicen que no es factible una inyección de este tipo, o que el escenario depende de muchas variables, en ejemplo,si se quisiera modificar la cabezera Referrer mediante alguna petición de tipo AJAX; la página desde donde se realiza la petición debería estar en el mismo dominio, esto debido a restricciones SOP, por tanto, de que serviría inyectar código JS/HTML, si ya se ha inyectado previamente para la petición? por tanto, este tipo de vulnerabilidades se cataloga como de poca importancia, sin embargo, el fin de esta explicación es encontrar una manera en la cuál la explotación sea exitosa sin demasiada ingeniería social.
Una vez descartada (aclaro, no del todo) el uso de una implementación AJAX para este ataque se debería encontrar una forma alternativa para modificar el campo suseptible, de forma que, si ponemos un poco de atención en el comportamiento del Header sabremos que el campo "permite al cliente especificar (en beneficio del servidor) la dirección URI del recurso desde el cuál el Request (N. del T. Petición) procede" [ Léase: http://tools.ietf.org/html/rfc2616 Apartado 14.36 Referer]. De forma que lo que el cliente necesitaría es proceder de una dirección de tipo <script>alert('Hi');<script> cosa que por el standard URI no es factible una dirección como tal, sin embargo, qué sucede si la página anterior fuera algo como http://evil.me/index.php?something=<script>alert('Hi')</script> ? aquí viene la explicación de porqué este ataque funciona en IE 6,7,8 y no en Mozilla. lo que Mozilla hace cada que el campo de referencia (Referer) es añadido a una petición es codificar en formato URL-Encode y entregar la información al server de forma que si del lado del cliente se refleja el XSS en algo como..
Código:
<html>
<head>
<Title>Oops! something went wrong</Title>
<body>
<h1>Sorry, we're in troubles</h1>
<i>please return to back page or click <a href="<? echo $_SERVER['HTTP_REFERER']; ?>">Here</a>.</i>
</body>
</head>
</html>
Como podemos ver, es posible modificar un poco la URL resultando en algo interpretable por el navegador: i.e. http://evil.me/index.php?something="><script>alert('Hi')</script><!--, ahora, en qué ocasiones es agregado el header por el navegador? Por mencionar algunas
1)Cuando el recurso proviene de una liga (Tag <a>)
2)Cuando el recurso proviene de un formulario (Tag <form>)
3)Cuando el recurso proviene de una redirección ( JS: document.location o Tag <meta>)
así que por facilidad ocuparemos la forma 3) debido a que creo que es la forma más corta y que no necesita interacción directa con el usuario obteniendo el mismo resultado.
de modo que haremos dos archivos, el primero para camuflajear la petición y que el URL no paresca tan maléfico, y el segundo para llegar a la víctima, de forma que el engaño seguiría la secuencia:
URL Normal, ejemplo, http://myserver.com/index.php el cual realizará una redirección a la página que contiene el código malicioso, ejemplo
Código:
<script>
document.location.href='http://evil.me/one.php?something="><script>alert("Hi")</script><!--';
</script>
Código:
<script>document.location.href="http://victim.com/vulnerableURL";<script>
de forma que el único reto será que el usuario entre a http://myserver.com/index.php
Bien eso es todo, espero haber aportado algo a la explotación del ataque, cualquier sugerencia quedo a su disposición. finalmente para ver una alternativa de código pueden visitar http://www.gremwell.com/exploiting_xss_in_referer_header
un saludo!