¿Qué es Cross Site Scripting (XSS)?

Cross Site Scripting (XSS) es una vulnerabilidad en una aplicación web que permite que un tercero ejecute un script en el navegador del usuario en nombre de la aplicación web. Cross-site Scripting es una de las vulnerabilidades más frecuentes presentes en la web hoy en día. La explotación de XSS contra un usuario puede tener varias consecuencias, como el compromiso de la cuenta, la eliminación de la cuenta, la escalada de privilegios, la infección por malware y muchas más.En sus inicios se llamaba CSS y no era exactamente lo que es hoy. Inicialmente, se descubrió que un sitio web malicioso podía utilizar JavaScript para leer datos de las respuestas de otros sitios web incrustándolos en un iframe, ejecutando scripts y modificando el contenido de la página. Entonces se llamaba CSS (Cross Site Scripting). La definición cambió cuando Netscape introdujo la Política del mismo origen y se restringió el uso de secuencias de comandos entre sitios para permitir la lectura de respuestas entre orígenes. Pronto se recomendó llamar a esta vulnerabilidad XSS para evitar confusiones con las hojas de estilo en cascada (CSS). La posibilidad de obtener XSSed surge cuando un sitio web no maneja correctamente la entrada proporcionada por un usuario antes de insertarla en la respuesta. En cuyo caso, se puede proporcionar una entrada diseñada que, cuando se incrusta en la respuesta, actúa como un bloque de código JS y el navegador la ejecuta. Dependiendo del contexto, haydos tipos de XSS –

1. XSS reflejado: si la entrada debe proporcionarse cada vez que se ejecute, dicho XSS se llama reflejado. Estos ataques se llevan a cabo principalmente mediante la entrega de una carga útil directamente a la víctima. La víctima solicita una página con una solicitud que contiene la carga útil y la carga útil viene incrustada en la respuesta como un script. Un ejemplo de XSS reflejado es XSS en el campo de búsqueda.
2. XSS almacenado: cuando la respuesta que contiene la carga útil se almacena en el servidor de tal manera que el script se ejecuta en cada visita sin enviar la carga útil, se identifica como XSS almacenado. Un ejemplo de XSS almacenado es XSS en el hilo de comentarios.

Hay otro tipo de XSS llamado XSS basado en DOM y sus instancias se reflejan o almacenan. XSS basado en DOM surge cuando los datos proporcionados por el usuario se proporcionan a los objetos DOM sin la desinfección adecuada. A continuación se muestra un ejemplo de código vulnerable a XSS, observe las variables nombre y apellido : 

<?php
 
   if(isset($_GET["firstname"]) && isset($_GET["lastname"]))
   {  
 
       $firstname = $_GET["firstname"];
       $lastname = $_GET["lastname"];   
 
       if($firstname == "" or $lastname == "")
       {
 
           echo "<font color=\"red\">Please enter both fields...</font>";      
 
       }
 
       else           
       {
 
           echo "Welcome " . $firstname. " " . $lastname;  
 
       }
   }
   ?>

La entrada proporcionada por el usuario se agrega directamente en la respuesta sin ninguna verificación de cordura. Atacante una entrada algo como – 

<script> alert(1) </script>

y se representará como JavaScript. Hay dos aspectos de XSS (y cualquier problema de seguridad):

1. Desarrollador: si es un desarrollador, el enfoque sería el desarrollo seguro para evitar que haya agujeros de seguridad en el producto. No necesita profundizar mucho en el aspecto de la explotación, solo tiene que usar herramientas y bibliotecas mientras aplica las mejores prácticas para el desarrollo de código seguro según lo prescrito por los investigadores de seguridad. Algunos recursos para los desarrolladores son: a). Proyecto de codificación OWASP: es una biblioteca escrita en Java desarrollada por Open Web Application Security Project (OWASP). Es gratis, de código abierto y fácil de usar. b). El encabezado «X-XSS-Protection»: este encabezado le indica al navegador que active el auditor XSS incorporado para identificar y bloquear cualquier intento de XSS contra el usuario. C). La hoja de trucos de protección XSS de OWASP:Este recurso enumera las reglas que se deben seguir durante el desarrollo con ejemplos adecuados. Las reglas cubren una gran variedad de casos en los que un desarrollador puede pasar por alto algo que puede hacer que el sitio web sea vulnerable a XSS. d). Política de seguridad de contenido: es una solución independiente para problemas similares a XSS, le indica al navegador sobre fuentes «seguras», aparte de las cuales no se debe ejecutar ningún script desde ningún origen.
2. Investigadores de seguridad: a los investigadores de seguridad, por otro lado, les gustaría contar con recursos similares que los ayuden a detectar instancias en las que el desarrollador se volvió pésimo y dejó un punto de entrada. Los investigadores pueden hacer uso de – a). CheatSheets – 1. Hoja de trucos de evasión de filtro XSS de OWASP. 2. Hoja de trucos XSS de Rodolfo Assis. 3. Hoja de trucos XSS de Veracode. b). Laboratorios de práctica: 1. bWAPP 2. DVWA (maldita aplicación web vulnerable) 3. prompt.ml 4. CTF c). Informes: 1. Hactividad de Hackerone 2. Blogs personales de investigadores de seguridad eminentes como Jason Haddix, Geekboy, Prakhar Prasad, Dafydd Stuttard (Portswigger), etc.