Considerada la vulnerabilidad más predominante en las aplicaciones web actuales [1], su relevancia se ha ido incrementando en el tiempo producto de su explotación y consecuencias.
Gran parte de esta sección hace referencia al capítulo 12 de "The Web Application Hacker's Handbook 2"
La explotación de una vulnerabilidad XSS puede ser realizada para llevar a cabo una serie de propósitos, tales como:
A continuación se analizará cada tipo, con buenas prácticas recomendadas que juntas representan la solución adecuada a estos tipos de ataques.
Se da cuando enviamos una petición donde incrustamos código Javascript que es reflejado a quien realiza la petición. Es fácil de encontrar y requiere cierta interacción para ser ejecutado por un tercero.
Está es la forma más común de mostrar datos que se suponen inocuos.
<p>
<?php
echo $_GET['nombre'];
?>
<p>
http://e.com/p.php?nombre=Juanito
<p> Juanito <p>
Se puede realizar una petición normal e incrustar código Javascript, algo no presupuestado por el desarrollador y que posibilita ciertos escenarios como robo de sesiones, etc.
http://e.com/p.php?nombre=Juanito<script>alert(1)</script>
<p> Juanito <script>alert(1)</script><p>
El código Javascript es ejecutado en el navegador.
Si se conoce el contexto de un dato solicitado, validarlo de acuerdo a su naturaleza, en este caso un nombre que sólo contenga carácteres válidos.
Se da cuando un usuario envía Javascript embebido en los datos que son almacenados en la aplicación y luego estos datos son mostrados a otros usuarios.
<?php
[...]
$address = $_POST['address'];
[...]
$place_id = save_place([...], $address); // 12345
?>
<?php
[...]
$address = get_address($place_id)
echo 'Dirección: '$address;
[...]
?>
POST [...]/place/12345/edit
[...]&address=Placeres
Datos guardados correctamente.
GET [...]/place/12345
Dirección: Placeres
Se puede realizar una petición normal e incrustar código Javascript, que será almacenado en la base de datos y gatillado cuando un usuario visite la página del lugar.
POST [...]/place/12345/edit
[...]&address=Placeres<img src="a.jpg"onerror=javascript:alert(6)>
Datos guardados correctamente.
GET [...]/place/12345
Dirección: Placeres<img src="a.jpg"onerror=javascript:alert(6)>
El código Javascript es ejecutado en el navegador.
Para desplegar datos suministrados por el usuario, es aconsejable codificar los carácteres usando codificación HTML. Para este caso, sería útil la función htmlspecialchars(), incluida en PHP.
Este tipo consiste en una serie de pasos:
Si las palabras que ingreso son agregadas al DOM y no pasan por una correcta sanitización, podría intentar crear un vector para ejecutar código Javascript arbitrario.
a"</li><<iframe/onload=alert("XSS")>
El código Javascript es ejecutado en el navegador.
En el lado del cliente también se deben realizar revisiones de la entrada de datos y como estos son agregados al DOM, debe ser aplicada una correcta codificación para evitar este tipo de ataques.
La explotación exitosa de una página susceptible a XSS depende en una serie de factores, tales como:
<script>alert(1)</script>
<img src=x onerror=alert(1)>
<embed src=javascript:alert(1)>
<x style=x:expression(alert(1))>
La idea es básicamente incrustar nuestro vector sin que esto provoque errores de síntaxis. Es necesario tener claro que:
Aplicar una validación dependiente del contexto de los datos.
Aplicar codificación a los datos antes de desplegarlos en la aplicación.
El propósito es enviar una petición a la aplicación vulnerable donde la víctima se encuentra autenticada para realizar acciones sin su consentimiento.
Esta vulnerabilidad viene dada porque la aplicación usa solo las cookies para llevar la pista de una sesión.
La petición de invitación en LinkedIn:
POST /fetch/manual-invite-create HTTP/1.1
Host: www.linkedin.com
[...]
emailAddresses=&subject=Invitation+to+connect+on+LinkedIn&csrfToken=ajax:1234567890123456789[...]
Podía ser simplificada a:
GET /fetch/manual-invite-create?emailAddresses=&subject=Invitation+to+connect+on+LinkedIn
Si no hay una verificación desde donde fue enviada la petición y la única validación de sesión se realiza mediante cookies, podría enviar esta petición aprovechando el hecho que un usuario se encuentra logueado en el sitio.
<img
src="http://www.linkedin.com/fetch/manual-invite-create?emailAddresses=<attacker_email>&subject="
width=0 height=0>
Para evitar este comportamiento, agregar un token al formulario y validarlo en el lado del servidor, con el objetivo de que no pueda ser realizada una petición cross-site éxitosamente.
La página objetivo en un iframe transparente, y se induce a la víctima a interactuar con objetos visibles (botones, imágenes, etc) siendo que realmente está haciendo click en la página dentro del iframe.
También es conocido como ClickJacking, StrokeJacking, entre otros nombres.
<script>
if (top.location != self.location)
{ top.location = self.location }
</script>
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.