El Cross-site Scripting (XSS) es una vulnerabilidad de los sitios web dinámicos en la que el atacante utiliza código malicioso para recopilar, manipular y redirigir información confidencial de usuarios desprevenidos que navegan y utilizan servicios públicos o privados disponibles en Internet.
Originalmente, el término se utilizaba para definir todos los ataques realizados mediante aplicaciones que explotaban el lenguaje javascript. Con el tiempo, esta definición también se ha ampliado para abarcar otras formas de inyectar código malicioso, como ActiveX, Java, VBscript, Flash e incluso HTML.
Cross-site Scripting: cómo funciona
El funcionamiento del Cross-site Scripting (XSS) es bastante sencillo. Básicamente, un posible atacante remoto podría “inyectar” código malicioso en la barra de direcciones junto con la URL tecleada por la víctima desprevenida, de forma que haga que el servidor web en el que está alojado el sitio que está visitando ejecute determinados comandos que solo se ejecutarán si el propio servidor ha sido mal configurado por los desarrolladores del sitio.
Insertando, por ejemplo, código javascript, un atacante puede robar datos sensibles contenidos en cookies de sesión, testigos de sesión, etc.
Las cookies de sesión, en particular, son simples archivos de texto utilizados para autenticarse en los servicios utilizados por la víctima. Un atacante que pudiera leer su contenido podría entonces hacerse pasar por la víctima y utilizar los distintos servicios en su lugar.
Para poner un ejemplo práctico, imaginemos que vamos a una discoteca tan mal gestionada que cuando compramos nuestra entrada nos dan un papel con nuestro nombre y apellido. Al cabo de un rato, entra otro tipo que nos ha estado espiando y nos ha oído hablar con el taquillero: se acerca a él y, en lugar de pagar la entrada, le da nuestros datos personales diciéndole que ha perdido la entrada y pidiéndole que le selle una nueva. En ese momento, el descuidado revisor le imprime un billete idéntico al nuestro y le deja pasar.
Comparemos ahora este ejemplo con el caso en que nos conectamos a un sitio de banca a domicilio o a cualquier otro tipo de servicio público o privado en el que ya estamos registrados, y que utilizamos normalmente para nuestros fines privados. Es fácil imaginar cuáles podrían ser las consecuencias.
Análisis técnico de un ataque
Para evitar un ataque de cross-site scripting (XSS), siempre es una buena idea analizar las cabeceras de los mensajes que recibimos de un servidor cuando hacemos una petición para visualizar una página web. Para ello, no es necesario utilizar herramientas de software avanzadas: incluso el navegador Chrome, por ejemplo, es suficiente.
Una vez abierta la página web que nos interesa, pulsamos la tecla F12 para entrar en modo Desarrollador. En la pantalla que aparece, nos movemos a la pestaña Red y escaneamos el contenido de la página para analizar las banderas de las cookies: la falta de banderas como HttpOnly, SameSite y Secure son sin duda un indicio de la escasa seguridad del sitio visitado. Veamos por qué:
-en primer lugar, si la bandera Httponly está activa, no se puede acceder a una cookie a través de un script del lado del cliente (que debe evaluarse si el navegador lo admite), por lo que incluso si la vulnerabilidad XSS estuviera presente y un usuario hiciera clic accidentalmente en el enlace malicioso, el propio navegador no revelaría la cookie de sesión a un usuario no autorizado;
-la bandera Samesite, por otra parte, impide los ataques de falsificación de petición entre sitios. Activarla es otra forma útil de prevenir otras actividades engañosas con el objetivo, esta vez, de utilizar el propio navegador del usuario sin necesidad de robar la cookie de sesión;
-por último, el atributo Secure. Activar la bandera correspondiente obliga a los navegadores a utilizar el protocolo HTTPS, una conexión cifrada que hace que la cookie sea ilegible para el atacante.
La bandera Secure, sin embargo, no es totalmente segura
Muchos sitios tienen a veces conexiones tanto en HTTPS como en HTTP. El protocolo HTTPS, en particular, permite cifrar el tráfico de Internet, lo que impide que un atacante vea una cookie con un texto plano legible.
Sin embargo, si el sitio también tiene la versión HTTP, un atacante podría obligar al usuario a autenticarse en el sitio a través de una conexión no cifrada manipulando la cabecera de la cookie establecida en la solicitud proporcionada al cliente por el servidor y sobrescribiendo la cookie de sesión que contiene el indicador Secure.
Esta cookie modificada se utilizará entonces en las solicitudes posteriores enviadas en HTTPS y así es como el XSS sigue sacando partido de las cosas, siempre que no se regeneren sesiones tras una autenticación correcta.
Ahora, supongamos que tenemos un sitio que no tiene ninguna de estas protecciones.
Imaginemos que tenemos en el código fuente de nuestra página un código PHP como el siguiente:
<?php echo $_GET[‘id’]; ?>
El comando get, suponiendo que tengamos una página dinámica llamada index.php, permite mostrar información diversificada sobre el contenido del sitio, por ejemplo recetas, tipos de coches, etc.
Si el enlace a la página de inicio es www.sitoesempio.it/index.php, un posible atacante remoto que utilice el método get podría insertar algunas instrucciones directamente dentro de la URL de la página precedidas de un signo de interrogación. Un ejemplo trivial es el siguiente:
www.paginaejemplo.com/index.php?id=10
Gracias a esta instrucción, el intérprete de PHP responderá que se está mostrando el artículo número 10.
Del mismo modo, un atacante podría añadir código javascript mucho más peligroso a la URL:
www.paginaejemplo.com/index.php?id=<script>alert(document.cookie);</script>.
Cuando el servidor procesa la petición de la página web indicada, el comando se ejecuta y el código inyectado es interpretado con normalidad por el navegador del usuario, ya que el desarrollador del sitio no ha pensado en prever o evitar de algún modo esta posibilidad.
El resultado es que el script document.cookie combinado con la variable alerta pondrá de manifiesto las cookies en forma de mensaje de advertencia.
Consejos para defenderse del Cross-site Scripting (XSS)
Obviamente, esto no es más que una simple prueba para entender cómo funciona un ataque XSS. Un posible hacker criminal podría sustituir este script implementando técnicas que, obviamente, no sean visibles para el usuario, para evitar que comprenda lo que está ocurriendo.
Por tanto, además de comprobar que el servidor web está configurado correctamente, nosotros mismos, como desarrolladores web, debemos darnos cuenta de que debemos proteger el código que desarrollamos para las aplicaciones de nuestros clientes y evitar que sea manipulado por usuarios malintencionados.
Dicho esto, es importante conocer las mejores prácticas en materia de validación, sanitización y escape de código, y así proteger eficazmente los datos sensibles de nuestros clientes frente a los ataques XSS.
Por parte del usuario, en cambio, para prevenir y protegerse de un ataque de tipo Cross-site Scripting, es necesario, en primer lugar, disponer de un buen antivirus en el ordenador y mantenerlo actualizado con las últimas firmas de virus disponibles.
También es importante mantener actualizado el navegador que utilizamos para navegar por Internet y, si es necesario, instalar una herramienta de análisis capaz de comprobar si hay vulnerabilidades en el código de un sitio web
