Cross Site Scripting (XSS) es uno de los ataques más populares y vulnerables que conocen todos los probadores avanzados. Se considera uno de los ataques con más riesgos para las aplicaciones web y también puede traer consecuencias perjudiciales.
XSS a menudo se compara con ataques similares del lado del cliente, ya que los lenguajes del lado del cliente se utilizan principalmente durante este ataque. Sin embargo, el ataque XSS se considera más peligroso, debido a su capacidad de dañar tecnologías aún menos vulnerables.
Aquí te proporcionamos la información sobre en qué consiste el ataque Cross Site Scripting, una descripción completa de sus tipos, herramientas y medidas preventivas con ejemplos perfectos en términos simples para su fácil comprensión.
Indice
¿Qué es el Cross Site Scripting?
El ataque Cross Site Scripting es una inyección de código malicioso, que se ejecutará en el navegador de la víctima. El script malicioso puede guardarse en el servidor web y ejecutarse cada vez que el usuario llama a la funcionalidad adecuada. También se puede realizar con los otros métodos, sin ningún script guardado en el servidor web.
El objetivo principal de este ataque es robar los datos de identidad del otro usuario: cookies, tokens de sesión y otra información. En la mayoría de los casos, este ataque se está utilizando para robar las cookies de la otra persona. Como sabemos, las cookies nos ayudan a iniciar sesión automáticamente. Por lo tanto, con las cookies robadas, podemos iniciar sesión con las otras identidades. Y esta es una de las razones por las cuales este ataque se considera uno de los más peligrosos.
El ataque XSS se está realizando en el lado del cliente. Se puede realizar con diferentes lenguajes de programación del lado del cliente. Sin embargo, la mayoría de las veces este ataque se realiza con Javascript y HTML.
¿Cómo se realiza este ataque?
El ataque de Cross Site Scripting significa enviar e inyectar código o script malicioso. El código malicioso generalmente se escribe con lenguajes de programación del lado del cliente como Javascript, HTML, VBScript , Flash, etc. Javascript y HTML se utilizan principalmente para realizar este ataque.
Este ataque se puede realizar de diferentes maneras. Dependiendo del tipo de ataque XSS, el script malicioso puede reflejarse en el navegador de la víctima o almacenarse en la base de datos y ejecutarse cada vez, cuando el usuario llama a la función apropiada.
La razón principal de este ataque es la validación de entrada del usuario inapropiada, donde la entrada maliciosa puede entrar en la salida. Un usuario malintencionado puede ingresar un script, que se inyectará en el código del sitio web. Entonces el navegador no puede saber si el código ejecutado es malicioso o no.
Por lo tanto, se está ejecutando un script malicioso en el navegador de la víctima o se está mostrando cualquier forma falsa para los usuarios. Hay varias formas en que puede ocurrir un ataque XSS.
Las formas principales de Cross Site Scripting son las siguientes:
- Cross Site Scripting puede ocurrir en el script malicioso ejecutado en el lado del cliente.
- Página o formulario falso que se muestra al usuario (donde la víctima escribe credenciales o hace clic en un enlace malicioso).
- En los sitios web con anuncios mostrados.
- Correos electrónicos maliciosos enviados a la víctima.
Este ataque ocurre cuando el usuario malintencionado encuentra las partes vulnerables del sitio web y lo envía como entrada maliciosa apropiada. Se inyecta un script malicioso en el código y luego se envía como salida al usuario final.
Ejemplos
Analicemos un ejemplo simple: considera que tenemos un sitio web con un campo de búsqueda.
Si el campo de búsqueda es vulnerable, cuando el usuario ingresa un script, se ejecutará.
Piensa que un usuario ingresa un script muy simple como se muestra a continuación: <script> alert (‘XSS’) </script>
Luego, después de hacer clic en el botón «Buscar» , se ejecutará la secuencia de comandos ingresada.
Entonces, el script escrito en el campo de búsqueda se ejecuta. Esto solo muestra la vulnerabilidad del ataque XSS. Sin embargo, también se puede escribir un script más dañino.
Muchos probadores mezclan el ataque Cross Site Scripting con Javascript Injection, que también se realiza en el lado del cliente. En ambos, se está inyectando el script malicioso de ataques. Sin embargo, en el caso de ataque XSS, las etiquetas <script> no son necesarias para ejecutar el script.
Por ejemplo: <body onload = alert (‘algo’)>
Analicemos otro ejemplo: considera que tenemos una página donde se muestra la última reseña de libro en el sitio web.
El código de esta página se verá como se muestra a continuación:
imprimir «<html>»
imprima «<h1> última reseña de libro </h1>»
print database.latestReview
imprimir «</html>»
Por lo tanto, en el campo de revisión, si un usuario malintencionado escribe algo dañino, se cargará en esta página.
Por ejemplo: si un hacker escribe el siguiente código en el campo de revisión: <script> destroyWebsite (); </script>
Luego, en la función de carga de la página destroyWebsite (); sería llamado y realizará sus acciones dañinas.
Este ataque se usa principalmente para reunir las cookies de la otra persona, que se pueden usar para iniciar sesión con las otras identidades. Analicemos otro ejemplo de posible script XSS con posible robo de cookies.
A través del campo del sitio web vulnerable, el hacker inyecta el código apropiado.
<script type = ”text / javascript”>
var test = ‘.. / example.php? cookie_data =’ + escape (document.cookie);
</script>
Como se ve en el Ejemplo indicado, las cookies se escapan y se envían a la variable ‘cookie_data’ del script example.php. Si el usuario malintencionado inyectara este script en el código del sitio web, se ejecutará en el navegador del usuario y se enviarán cookies al usuario malintencionado.
Tipos
El objetivo principal de realizar un ataque XSS es robar la identidad de otra persona. Como se mencionó, pueden ser cookies, tokens de sesión, etc. XSS también se puede usar para mostrar páginas o formularios falsificados para la víctima. Sin embargo, este ataque se puede realizar de varias maneras.
Este ataque se divide en tres categorías principales como se muestra a continuación:
- XSS reflejado: este ataque se produce cuando un script malicioso no se guarda en el servidor web, sino que se refleja en los resultados del sitio web.
- XSS almacenado: este ataque se produce cuando un script malicioso se guarda de forma permanente en el servidor web.
- DOM: esto ocurre cuando se cambia el entorno DOM, pero el código sigue siendo el mismo.
Vamos a analizar en profundidad a cada uno de ellos.
1. XSS reflejado
Esto ocurre cuando se devuelven los resultados maliciosos después de ingresar el código malicioso. El código XSS reflejado no se guarda de forma permanente. En este caso, el código malicioso se refleja en el resultado de cualquier sitio web. El código de ataque se puede incluir en la URL falsa o en los parámetros HTTP.
Puede afectar a la víctima de diferentes maneras: al mostrar una página maliciosa falsa o al enviar un correo electrónico malicioso.
Analicemos un ejemplo: considera que tenemos una página de inicio de sesión, donde el usuario tiene que escribir su nombre de usuario y contraseña.
En algunos sitios web cuando se escriben credenciales incorrectas, se mostrará un mensaje de error como «Lo siento, su nombre de usuario o sus credenciales son incorrectas».
En este ejemplo, el nombre de usuario es un parámetro que el usuario escribe en el formulario de inicio de sesión. Incluir el parámetro de nombre de usuario en la salida es un error. De esta manera, un atacante puede escribir el script malicioso en lugar del nombre de usuario o dirección de correo electrónico correctos.
Por ejemplo, puede ser un script, que se envía a la dirección de correo electrónico maliciosa del usuario, donde la víctima puede hacer clic en el enlace falso.
2. XSS almacenado
Este ataque puede considerarse más peligroso ya que produce más daño.
En este tipo de ataque, el código o script malicioso se guarda en el servidor web (por ejemplo, en la base de datos) y se ejecuta cada vez que los usuarios llaman a la funcionalidad adecuada. De esta manera, el ataque XSS almacenado puede afectar a muchos usuarios. Además, a medida que el script se almacena en el servidor web, afectará al sitio web durante más tiempo.
Para realizar un ataque XSS almacenado, el script malicioso debe enviarse a través del formulario de entrada vulnerable (por ejemplo, campo de comentario o campo de revisión). De esta forma, el script se guardará en la base de datos y se ejecutará en la carga de la página o en la llamada a la función adecuada.
Ten en cuenta que tenemos una página donde se carga la última opinión del usuario. Por lo tanto, en el campo de opinión o comentario se escribiría con el script como se muestra a continuación: <script> alert (document.cookie) </script>
Se guardará en la base de datos y se ejecutará en la carga de la página, ya que la última opinión del usuario se mostrará en la página. Si un sitio web es vulnerable a XSS, se mostrará en la página la ventana emergente de carga con cookies. Este script es bastante simple y menos dañino. Sin embargo, en lugar de este script, se puede ingresar un código más dañino.
Por ejemplo, se pueden enviar cookies al usuario malintencionado o se puede mostrar una página falsa en el navegador de la víctima.
3. DOM XSS
Este tipo de ataque ocurre cuando se cambia el entorno DOM, pero el código del lado del cliente no cambia. Cuando el entorno DOM se modifica en el navegador de la víctima, el código del lado del cliente se ejecuta de manera diferente.
Para comprender mejor cómo se realiza el ataque XSS DOM, analicemos el siguiente ejemplo.
Piensa que hay una página web con URL http://testing.com/book.html?default=1 . «Predeterminado» es un parámetro y «1» es su valor. Por lo tanto, para realizar un ataque XSS DOM, enviaríamos un script como parámetro.
Por ejemplo: http://testing.com/book.html?default= <script> alert (document.cookie) </script>
En este ejemplo, la solicitud se envía para la página book.html? Default = <script> alert (document.cookie) </ script > a testing.com. Por lo tanto, para esa página, el navegador está creando un objeto DOM, donde el objeto de ubicación del documento contendrá la cadena apropiada: http://testing.com/book.html?default= <script> alert (document.cookie) </script>
De esta manera, el entorno DOM se ve afectado. Por supuesto, en lugar de este simple script, también se puede ingresar algo más dañino.
Comparación con otros ataques
XSS se considera uno de los ataques con más riesgos, ya que su objetivo principal es robar las identidades de usuario del sitio web o del sistema. Para llevar a cabo un ataque XSS pueden utilizarse distintos lenguajes del lado del cliente como Javascript, HTML, VBScript, Flash, etc. Y esto lo hace más dañino y extendido que los otros posibles ataques.
La prueba de ataque XSS es bastante similar a la prueba de otros posibles ataques del lado del cliente. Sin embargo, es importante recordar qué casos adicionales deben verificarse durante la prueba de XSS.
Otra cosa que hace que este ataque tenga más riesgos es la posibilidad de ser almacenado en el servicio web, de esta manera puede afectar a muchos usuarios por un período de tiempo más largo. XSS a veces se puede realizar a sistemas aún menos vulnerables y sus vulnerabilidades a veces son difíciles de encontrar.
Además, mientras se compara con los otros ataques, XSS tiene muchas formas de realizarse y afectar el sitio web también.
¿Cómo probar un ataque XSS?
En primer lugar, para probar el ataque XSS, se pueden realizar pruebas de caja negra.
Significa que se puede probar sin una revisión de código. Sin embargo, la revisión de código siempre es una práctica recomendada y también brinda resultados más confiables. Si se selecciona una buena técnica de prueba de caja negra y se realiza con precisión, esto debería ser suficiente.
Al comenzar las pruebas, un probador debe considerar qué partes del sitio web son vulnerables al posible ataque XSS.
Es mejor enumerarlos en cualquier documento de prueba y de esta manera estaremos seguros de que no se perderá nada. Luego, el probador debe planificar qué código o campos de entrada de script deben verificarse. Es importante recordar, lo que significan los resultados, que la aplicación es vulnerable y analiza los resultados a fondo.
Mientras se prueba un posible ataque, es importante verificar cómo se responde a los scripts escritos y si esos scripts se ejecutan o no.
Además, mientras se realiza una prueba manual para detectar posibles ataques de Cross Site Scripting, es importante recordar que los corchetes codificados también deben probarse.
Algunas personas intentan proteger los sitios web y los sistemas de varios ataques cambiando los corchetes a doble.
No debemos olvidarnos de probar la URL del sitio web.
En general, mientras se prueba un posible ataque XSS, se debe verificar la validación de entrada y el probador debe estar consciente al verificar la salida del sitio web. Además, si se está realizando una revisión de código, es importante encontrar cómo la entrada puede entrar en la salida.
Herramientas de prueba
Dado que el ataque Cross Site Scripting es uno de los peligrosos ataques más populares, existen muchas herramientas para probarlo automáticamente. Podemos encontrar varios escáneres para verificar posibles vulnerabilidades de ataque XSS, como Nesus y Nikto. Ambos se consideran bastante confiables.
Es importante mencionar la herramienta SOAP UI. Se puede considerar como una herramienta bastante sólida para verificar los posibles ataques XSS. Contiene plantillas listas para verificar este ataque. Realmente simplifica el proceso de prueba.
Sin embargo, para probar esta vulnerabilidad con la herramienta SOAP UI, las pruebas de nivel API ya deberían estar automatizadas con esa herramienta. Otra solución para probar un XSS pueden ser los complementos del navegador. Sin embargo, los complementos se consideran una herramienta bastante débil para verificar este tipo de ataque.
Incluso mientras realiza las pruebas automáticamente, el probador debe tener un buen conocimiento de este tipo de ataque y debe poder analizar los resultados adecuadamente.
Un buen conocimiento también es útil al seleccionar la herramienta de prueba. Además, es importante saber que, mientras realiza el análisis de vulnerabilidades de seguridad con una herramienta automática, las pruebas manuales también son una buena práctica y de esta manera el probador podrá ver los resultados y analizarlos.
Herramienta recomendada: Kiuwan
Encuentra y repara vulnerabilidades en su código en cada etapa del SDLC.
Kiuwan cumple con los estándares de seguridad más estrictos, incluidos OWASP, CWE, SANS 25, HIPPA y más. Integra Kiuwan en tu IDE para obtener comentarios instantáneos durante el desarrollo.
Kiuwan admite todos los principales lenguajes de programación y se integra con las principales herramientas de DevOps.
Prevenir el Cross Site Scripting
Aunque este tipo de ataque se considera uno de los más peligrosos, se debe preparar un plan de prevención. Debido a la popularidad de este ataque, hay muchas maneras de prevenirlo.
Los principales métodos de prevención utilizados comúnmente incluyen:
- Validación de datos
- Filtración
- Escapar
El primer paso en la prevención de este ataque es la validación de entrada. Todo lo que ingrese el usuario debe validarse con precisión, porque la entrada del usuario puede encontrar su camino hacia la salida. La validación de datos se puede nombrar como la base para garantizar la seguridad del sistema.
Esto solo ayuda a reducir los riesgos, pero puede no ser suficiente para prevenir la posible vulnerabilidad XSS.
Otro buen método de prevención es el filtrado de entrada del usuario. La idea del filtrado es buscar palabras clave peligrosas en la entrada del usuario y eliminarlas o reemplazarlas por cadenas vacías.
Esas palabras clave pueden ser:
- Etiquetas <script> </script>
- Comandos Javascript
- Marcado HTML
El filtrado de entrada es bastante fácil de practicar. También se puede realizar de diferentes maneras:
- Por desarrolladores que han escrito código del lado del servidor.
- Se está utilizando la biblioteca del lenguaje de programación apropiado.
En este caso, algunos desarrolladores escriben su propio código para buscar las palabras clave apropiadas y eliminarlas. Sin embargo, la forma más fácil sería seleccionar la biblioteca de lenguajes de programación adecuada para filtrar la entrada del usuario. El uso de bibliotecas es una forma más confiable, ya que esas bibliotecas fueron utilizadas y probadas por muchos desarrolladores.
Otro posible método de prevención es la fuga de caracteres. En esta práctica, los caracteres apropiados están siendo cambiados por códigos especiales. Es importante saber que podemos encontrar bibliotecas apropiadas para escapar de los caracteres.
Mientras tanto, las buenas pruebas no deben olvidarse también. Debe invertirse en buenos conocimientos de probadores de software y herramientas confiables de prueba de software. De esta manera, la buena calidad del software estará mejor asegurada.
Prevención según tecnologías
Como ya indicamos, el filtrado y el escape de caracteres son los principales métodos de prevención. Sin embargo, se puede realizar de manera diferente en diferentes lenguajes de programación. Algunos lenguajes de programación tienen bibliotecas de filtrado apropiadas y otros no.
Cabe mencionar que el filtrado se puede realizar con bastante facilidad en los lenguajes de programación Java y PHP, ya que tienen bibliotecas apropiadas para ello.
La tecnología Java es bastante utilizada, por lo tanto, existen muchas soluciones. Si estás utilizando la tecnología Spring y deseas escapar de HTML para toda la aplicación, debes escribir el código apropiado en el archivo web.xml del proyecto.
Hay muchos filtros XSS listos en forma de archivo .jar. Ese archivo .jar debe agregarse a su proyecto y solo entonces se pueden usar sus bibliotecas. Uno de estos filtros XSS es xssflt.jar, que es un filtro de servlet. Este archivo .jar puede descargarse fácilmente de Internet y agregarse a su proyecto.
Este filtro verifica cada solicitud que se envía a la aplicación y la limpia de una posible inyección.
Otra posible solución es la biblioteca ESAPI. La biblioteca ESAPI es compatible con muchos lenguajes de programación. Puedes encontrar bibliotecas ESAPI para lenguajes de programación Java y PHP. Es una biblioteca de código abierto y gratuita, que ayuda a controlar la seguridad de la aplicación.
XSS Cheat Sheets
XSS Cheat Sheets puede ser muy útil para la prevención de Cross Site Scripting. Es una guía para desarrolladores sobre cómo evitar los ataques XSS. Las reglas son muy útiles y no deben olvidarse durante el desarrollo. Las hojas de trucos XSS se pueden encontrar en comunidades de Internet como OWASP.
Hay diferentes tipos de hojas de trucos:
- de prevención XSS
- DOM XSS
- de evasión del filtro XSS
La directriz principal sería la Hoja de trucos de prevención XSS, ya que proporciona reglas comunes para la prevención de ataques XSS. Si sigues las reglas de la Hoja de trucos DOM XSS y la Hoja de trucos de evasión del filtro XSS, todavía tendrías que seguir la Hoja de trucos de prevención XSS.
Como se indicó, la hoja de trucos de prevención XSS se puede encontrar en la comunidad OWASP. Esta Cheat Sheet nos proporciona una lista de reglas que nos ayudarían a reducir los riesgos de posibles ataques XSS. No son solo las reglas de codificación, sino también las vulnerabilidades de seguridad con carácter preventivo.
Algunas de las reglas incluyen:
- No se deben insertar datos que no sean de confianza.
- El HTML debe escaparse antes de insertar datos no confiables.
- El atributo se debe escapar antes de insertar los datos no confiables, etc.
Por lo tanto, Cheat Sheet puede ser muy útil para prevenir este tipo de ataques.
Como ya hemos indicado, el ataque XSS es uno de los más dañinos. Por lo tanto, no debemos olvidar este tipo de pruebas. Al realizar pruebas contra XSS, es importante tener un buen conocimiento sobre este ataque. Y esta es la base para analizar los resultados de las pruebas correctamente y elegir las herramientas de prueba adecuadas.