diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index be4d4275a..4c7d77d24 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -725,6 +725,7 @@
- [SOME - Same Origin Method Execution](pentesting-web/xss-cross-site-scripting/some-same-origin-method-execution.md)
- [Sniff Leak](pentesting-web/xss-cross-site-scripting/sniff-leak.md)
- [Steal Info JS](pentesting-web/xss-cross-site-scripting/steal-info-js.md)
+ - [Wasm Linear Memory Template Overwrite Xss](pentesting-web/xss-cross-site-scripting/wasm-linear-memory-template-overwrite-xss.md)
- [XSS in Markdown](pentesting-web/xss-cross-site-scripting/xss-in-markdown.md)
- [XSSI (Cross-Site Script Inclusion)](pentesting-web/xssi-cross-site-script-inclusion.md)
- [XS-Search/XS-Leaks](pentesting-web/xs-search/README.md)
diff --git a/src/pentesting-web/xss-cross-site-scripting/README.md b/src/pentesting-web/xss-cross-site-scripting/README.md
index 1aae99d1f..07b958654 100644
--- a/src/pentesting-web/xss-cross-site-scripting/README.md
+++ b/src/pentesting-web/xss-cross-site-scripting/README.md
@@ -4,65 +4,65 @@
## Metodología
-1. Comprueba si **algún valor que controlas** (_parameters_, _path_, _headers_?, _cookies_?) se está **reflejando** en el HTML o **si es usado** por código **JS**.
+1. Comprueba si **algún valor que controlas** (_parameters_, _path_, _headers_?, _cookies_?) está siendo **reflejado** en el HTML o **usado** por código **JS**.
2. **Encuentra el contexto** donde se refleja/usa.
3. Si está **reflejado**
1. Comprueba **qué símbolos puedes usar** y, dependiendo de eso, prepara el payload:
-1. En **HTML sin procesar**:
+1. En **raw HTML**:
1. ¿Puedes crear nuevas etiquetas HTML?
2. ¿Puedes usar eventos o atributos que soporten el protocolo `javascript:`?
-3. ¿Puedes eludir protecciones?
-4. ¿El contenido HTML está siendo interpretado por algún engine JS del lado cliente (_AngularJS_, _VueJS_, _Mavo_...)? podrías abusar de un [**Client Side Template Injection**](../client-side-template-injection-csti.md).
+3. ¿Puedes bypassar protecciones?
+4. ¿El contenido HTML está siendo interpretado por algún motor JS del cliente (_AngularJS_, _VueJS_, _Mavo_...)? podrías abusar de un [**Client Side Template Injection**](../client-side-template-injection-csti.md).
5. Si no puedes crear etiquetas HTML que ejecuten código JS, ¿podrías abusar de un [**Dangling Markup - HTML scriptless injection**](../dangling-markup-html-scriptless-injection/index.html)?
2. Dentro de una **etiqueta HTML**:
-1. ¿Puedes salir al contexto de HTML sin procesar?
+1. ¿Puedes salir al contexto raw HTML?
2. ¿Puedes crear nuevos eventos/atributos para ejecutar código JS?
3. ¿El atributo en el que estás atrapado soporta ejecución de JS?
-4. ¿Puedes eludir protecciones?
+4. ¿Puedes bypassar protecciones?
3. Dentro de **código JavaScript**:
1. ¿Puedes escapar la etiqueta ``** tags de una página HTML, dentro de un archivo `.js` o dentro de un atributo que usa el protocolo **`javascript:`**:
+In this case your input is reflected between **``** tags of a HTML page, inside a `.js` file or inside an attribute using **`javascript:`** protocol:
-- Si se refleja entre **``** tags, incluso si tu entrada está dentro de cualquier tipo de comillas, puedes intentar inyectar `` y escapar de este contexto. Esto funciona porque el **navegador primero analizará las etiquetas HTML** y luego el contenido, por lo tanto, no notará que tu etiqueta `` inyectada está dentro del código HTML.
-- Si se refleja **dentro de una JS string** y el truco anterior no funciona necesitarías **salir** de la cadena, **ejecutar** tu código y **reconstruir** el código JS (si hay algún error, no se ejecutará:
+- If reflected between **``** tags, even if your input if inside any kind of quotes, you can try to inject `` and escape from this context. This works because the **browser will first parse the HTML tags** and then the content, therefore, it won't notice that your injected `` tag is inside the HTML code.
+- If reflected **inside a JS string** and the last trick isn't working you would need to **exit** the string, **execute** your code and **reconstruct** the JS code (if there is any error, it won't be executed:
- `'-alert(1)-'`
- `';-alert(1)//`
- `\';alert(1)//`
-- Si se refleja dentro de template literals puedes **embed JS expressions** usando la sintaxis `${ ... }`: `` var greetings = `Hello, ${alert(1)}` ``
-- **Unicode encode** works to write **valid javascript code**:
+- If reflected inside template literals you can **embed JS expressions** using `${ ... }` syntax: `` var greetings = `Hello, ${alert(1)}` ``
+- **Unicode encode** funciona para escribir **código javascript válido**:
```javascript
alert(1)
alert(1)
@@ -86,7 +86,7 @@ alert(1)
```
#### Javascript Hoisting
-Javascript Hoisting hace referencia a la posibilidad de **declarar funciones, variables o clases después de que se usan, de modo que puedes abusar de escenarios donde un XSS está usando variables o funciones no declaradas.**\
+Javascript Hoisting se refiere a la posibilidad de **declarar funciones, variables o clases después de que se usan, de modo que puedes abusar de escenarios donde un XSS está usando variables o funciones no declaradas.**\
**Consulta la siguiente página para más información:**
@@ -94,17 +94,17 @@ Javascript Hoisting hace referencia a la posibilidad de **declarar funciones, va
js-hoisting.md
{{#endref}}
-### Función de Javascript
+### Javascript Function
Varias páginas web tienen endpoints que **aceptan como parámetro el nombre de la función a ejecutar**. Un ejemplo común en entornos reales es algo como: `?callback=callbackFunc`.
-Una buena forma de detectar si algo que viene directamente del usuario está intentando ejecutarse es **modificar el valor del parámetro** (por ejemplo a 'Vulnerable') y mirar en la consola errores como:
+Una buena forma de averiguar si algo proporcionado directamente por el usuario intenta ser ejecutado es **modificar el valor del parámetro** (por ejemplo a 'Vulnerable') y buscar en la consola errores como:
.png>)
Si es vulnerable, podrías ser capaz de **disparar un alert** simplemente enviando el valor: **`?callback=alert(1)`**. Sin embargo, es muy común que estos endpoints **validen el contenido** para permitir solo letras, números, puntos y guiones bajos (**`[\w\._]`**).
-Sin embargo, incluso con esa limitación todavía es posible realizar algunas acciones. Esto se debe a que puedes usar esos caracteres válidos para **acceder a cualquier elemento del DOM**:
+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 del DOM**:
.png>)
@@ -116,11 +116,11 @@ nextElementSibiling
lastElementSibiling
parentElement
```
-También puedes intentar invocar **Javascript functions** directamente: `obj.sales.delOrders`.
+También puedes intentar **invocar funciones Javascript** directamente: `obj.sales.delOrders`.
-Sin embargo, normalmente los endpoints que ejecutan la función indicada son endpoints sin un DOM muy interesante; otras páginas en la misma origin tendrán un DOM más interesante para realizar más acciones.
+Sin embargo, por lo general los endpoints que ejecutan la función indicada son endpoints sin un DOM muy interesante, **otras páginas del mismo origen** tendrán un **DOM más interesante** para realizar más acciones.
-Por lo tanto, para abusar de esta vulnerabilidad en un DOM diferente se desarrolló la explotación Same Origin Method Execution (SOME):
+Por lo tanto, para **abusar de esta vulnerabilidad en un DOM diferente** se desarrolló la explotación **Same Origin Method Execution (SOME)**:
{{#ref}}
@@ -129,7 +129,7 @@ some-same-origin-method-execution.md
### DOM
-Hay código JS que está usando de forma insegura algunos datos controlados por un atacante, como `location.href`. Un atacante podría abusar de esto para ejecutar código JS arbitrario.
+Hay **JS code** que está utilizando de forma **insegura** algunos **datos controlados por un atacante** como `location.href`. Un atacante podría abusar de esto para ejecutar código JS arbitrario.
{{#ref}}
@@ -138,7 +138,7 @@ dom-xss.md
### **Universal XSS**
-Este tipo de XSS se puede encontrar en cualquier lugar. No dependen únicamente de la explotación en el cliente de una aplicación web, sino de cualquier contexto. Este tipo de ejecución arbitraria de JavaScript incluso puede ser abusada para obtener RCE, leer archivos arbitrarios en clientes y servidores, y más.\
+Estos tipos de XSS pueden encontrarse **en cualquier lugar**. No dependen únicamente de la explotación del cliente de una aplicación web sino de **cualquier** **contexto**. Estos tipos de **ejecución arbitraria de JavaScript** incluso pueden usarse para obtener **RCE**, **leer** **archivos** **arbitrarios** en clientes y servidores, y más.\
Algunos **ejemplos**:
@@ -151,17 +151,17 @@ server-side-xss-dynamic-pdf.md
../../network-services-pentesting/pentesting-web/electron-desktop-apps/
{{#endref}}
-## Imagen de codificación para bypass de WAF
+## WAF bypass encoding image
.jpg>)
-## Inyección dentro de HTML crudo
+## Injecting inside raw HTML
-Cuando tu input 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 comprobar si puedes abusar de `<` para crear nuevas etiquetas: simplemente intenta reflejar ese carácter y verifica si está siendo HTML encoded o eliminado, o si se refleja sin cambios. Solo en este último caso podrás explotar esta situación.\
-Para estos casos también ten en cuenta [**Client Side Template Injection**](../client-side-template-injection-csti.md).\
-_**Nota: Un comentario HTML puede cerrarse usando `-->` o `--!>`**_
+Cuando tu input se refleja **dentro de la página HTML** o puedes escapar e inyectar código HTML en este contexto, lo **primero** que necesitas hacer es comprobar si puedes abusar de `<` para crear nuevas etiquetas: simplemente intenta **reflejar** ese **carácter** y comprueba si está siendo **codificado en HTML** o **eliminado** o si se **refleja sin cambios**. **Solo en este último caso podrás explotar esta situación**.\
+Para estos casos también **ten en cuenta** [**Client Side Template Injection**](../client-side-template-injection-csti.md)**.**\
+_**Nota: A HTML comment can be closed using\*\***\***\*`-->`\*\***\***\*or \*\***`--!>`\*\*_
-En este caso, y si no se usa black/whitelisting, podrías usar payloads como:
+En este caso y si no se usa black/whitelisting, podrías usar payloads como:
```html
` o entre eventos HTML que pueden ejecutar código JS o entre atributos que aceptan el protocolo `javascript:`.
+En estos casos tu **input** va a ser **reflejado dentro del código JS** de un archivo `.js` o entre etiquetas `` o entre eventos HTML que pueden ejecutar código JS o entre atributos que aceptan el protocolo `javascript:`.
### Escapando la etiqueta \` podrías fácilmente **escapar cerrando la etiqueta `` podrías fácilmente **escapar cerrando la etiqueta `
```
-Ten en cuenta que en este ejemplo **ni siquiera hemos cerrado la comilla simple**. Esto se debe a que **el análisis HTML se realiza primero por el navegador**, lo que implica identificar elementos de la página, incluidos bloques de script. El parseo de JavaScript para entender y ejecutar los scripts incrustados se lleva a cabo solo después.
+Ten en cuenta que en este ejemplo **ni siquiera hemos cerrado la comilla simple**. Esto se debe a que **el análisis de HTML se realiza primero por el navegador**, lo que implica identificar los elementos de la página, incluidos los bloques de script. El análisis de JavaScript para entender y ejecutar los scripts incrustados solo se realiza después.
-### Inside JS code
+### Dentro del código JS
-Si `<>` están siendo sanitised todavía puedes **escapar la cadena** donde se encuentra tu entrada y **ejecutar JS arbitrario**. Es importante **corregir la sintaxis de JS**, porque si hay errores, el código JS no se ejecutará:
+Si `<>` están siendo sanitizados puedes aún **escapar la cadena** donde se está **ubicando** tu entrada y **ejecutar JS arbitrario**. Es importante **corregir la sintaxis de JS**, porque si hay errores, el código JS no se ejecutará:
```
'-alert(document.domain)-'
';alert(document.domain)//
@@ -497,7 +497,7 @@ Si `<>` están siendo sanitised todavía puedes **escapar la cadena** donde se e
```
#### JS-in-JS string break → inject → repair pattern
-Cuando la entrada del usuario cae dentro de una cadena JavaScript entrecomillada (p. ej., echo del lado del servidor dentro de un inline script), puedes terminar la cadena, inyectar código y reparar la sintaxis para mantener el parsing válido. Esqueleto genérico:
+Cuando la entrada del usuario cae dentro de una cadena JavaScript entre comillas (p. ej., eco del lado del servidor dentro de un script en línea), puedes terminar la cadena, inyectar código y reparar la sintaxis para que el parseo siga siendo válido. Esqueleto genérico:
```
" // end original string
; // safely terminate the statement
@@ -508,11 +508,12 @@ Ejemplo de patrón de URL cuando el parámetro vulnerable se refleja en una cade
```
?param=test";;a="
```
-Esto ejecuta JS del atacante sin necesitar tocar el contexto HTML (pure JS-in-JS). Combina con los blacklist bypasses abajo cuando los filtros bloqueen palabras clave.
+Esto ejecuta JS del atacante sin necesidad de tocar el contexto HTML (pure JS-in-JS). Combínalo con blacklist bypasses más abajo cuando los filtros bloqueen palabras clave.
### Literales de plantilla \`\`
-Para construir **strings**, además de comillas simples y dobles, JS también acepta **backticks** **` `` `**. Esto se conoce como literales de plantilla ya que permiten **incrustar expresiones JS** usando la sintaxis `${ ... }`.\ Por lo tanto, si encuentras que tu entrada se está **reflejando** dentro de una JS string que usa backticks, 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 **incrustar expresiones JS** usando la sintaxis `${ ... }`.\
+Por lo tanto, si descubres que tu entrada está siendo **reflejada** dentro de una cadena JS que usa backticks, puedes abusar de la sintaxis `${ ... }` para ejecutar **código JS arbitrario**:
Esto puede ser **abusado** usando:
```javascript
@@ -526,21 +527,21 @@ return loop
}
loop``
```
-### Encoded code execution
+### Ejecución de código codificado
```html
This is a 1 line comment, but "-->" must to be at the beggining of the first line
```
-**JavaScript new lines (del** [**JavaScript new line**](#javascript-new-lines) **truco)**
+**JavaScript new lines (de** [**JavaScript new line**](#javascript-new-lines) **truco)**
```javascript
//Javascript interpret as new line these chars:
String.fromCharCode(10)
@@ -715,7 +716,7 @@ try{throw onerror=alert}catch{throw 1}
- [https://github.com/RenwaX23/XSS-Payloads/blob/master/Without-Parentheses.md](https://github.com/RenwaX23/XSS-Payloads/blob/master/Without-Parentheses.md)
- [https://portswigger.net/research/javascript-without-parentheses-using-dommatrix](https://portswigger.net/research/javascript-without-parentheses-using-dommatrix)
-**Llamada arbitraria a una función (alert)**
+**Llamada arbitraria a la función (alert)**
```javascript
//Eval like functions
eval('ale'+'rt(1)')
@@ -777,8 +778,8 @@ top[8680439..toString(30)](1)
```
## **Vulnerabilidades DOM**
-Hay **JS code** que está usando **datos controlados de forma insegura por un atacante** 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** [**DOM vulnerabilities it was moved to this page**](dom-xss.md)**:**
+Hay **JS code** que está usando **datos de forma insegura controlados por un atacante** 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 movieron a esta página**](dom-xss.md)**:**
{{#ref}}
@@ -786,44 +787,55 @@ dom-xss.md
{{#endref}}
Allí encontrarás una **explicación detallada de qué son las vulnerabilidades DOM, cómo se provocan y cómo explotarlas**.\
-También, no olvides que **al final del post mencionado** puedes encontrar una explicación sobre [**DOM Clobbering attacks**](dom-xss.md#dom-clobbering).
+También, no olvides que **al final de la entrada mencionada** puedes encontrar una explicación sobre [**DOM Clobbering attacks**](dom-xss.md#dom-clobbering).
### Escalando Self-XSS
### Cookie XSS
-Si puedes desencadenar un XSS enviando el payload dentro de una cookie, esto suele ser un self-XSS. Sin embargo, si encuentras un **subdominio vulnerable a XSS**, podrías abusar de ese XSS para inyectar una cookie en todo el dominio, logrando activar el cookie XSS en el dominio principal u otros subdominios (los que sean vulnerables a cookie XSS). Para esto puedes usar el cookie tossing attack:
+Si puedes trigger un XSS enviando el payload dentro de una cookie, esto suele ser un self-XSS. Sin embargo, si encuentras un **subdominio vulnerable a XSS**, podrías abusar de ese 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 cookie tossing attack:
{{#ref}}
../hacking-with-cookies/cookie-tossing.md
{{#endref}}
-Puedes encontrar un gran abuso de esta técnica en [**this blog post**](https://nokline.github.io/bugbounty/2024/06/07/Zoom-ATO.html).
+Puedes encontrar un gran abuso de esta técnica en [**esta entrada del blog**](https://nokline.github.io/bugbounty/2024/06/07/Zoom-ATO.html).
-### Enviar tu sesión al administrador
+### Enviando tu sesión al administrador
-Quizá un usuario pueda compartir su perfil con el administrador y si el self XSS está dentro del perfil del usuario y el administrador lo accede, éste desencadenará la vulnerabilidad.
+Quizás un usuario pueda compartir su perfil con el administrador y, si el self XSS está dentro del perfil del usuario y el administrador lo accede, se disparará la vulnerabilidad.
### Session Mirroring
-Si encuentras algún self XSS y la web tiene **session mirroring for administrators**, por ejemplo permitiendo a clientes pedir ayuda y para que el administrador te ayude él verá lo que tú estás viendo en tu sesión pero desde su sesión.
+Si encuentras un self XSS y la web tiene un **session mirroring for administrators**, por ejemplo permitiendo a los clientes pedir ayuda y, para que el administrador te ayude, él verá lo que estás viendo en tu sesión pero desde su propia sesión.
-Podrías conseguir que el administrador desencadene tu self XSS y robar sus cookies/sesión.
+Podrías hacer que el **administrador dispare tu self XSS** y robar sus cookies/sesión.
## Otros Bypasses
+### Bypassing sanitization via WASM linear-memory template overwrite
+
+Cuando una web app usa Emscripten/WASM, las cadenas constantes (como stubs de formato HTML) residen en memoria lineal escribible. Un único desbordamiento dentro del WASM (p. ej., memcpy sin comprobar en una ruta de edición) puede corromper estructuras adyacentes y redirigir escrituras hacia esas constantes. Sobrescribir una plantilla como "
%.*s
" por "" convierte la entrada sanitizada en un valor de handler de JavaScript y produce un DOM XSS inmediato al renderizar.
+
+Consulta la página dedicada con el flujo de explotación, DevTools memory helpers y defensas:
+
+{{#ref}}
+wasm-linear-memory-template-overwrite-xss.md
+{{#endref}}
+
+
### Unicode normalizado
-Puedes comprobar si los **valores reflejados** están siendo **normalizados en Unicode** en el servidor (o en el cliente) y abusar de esta funcionalidad para eludir protecciones. [**Find an example here**](../unicode-injection/index.html#xss-cross-site-scripting).
+Puedes comprobar si los **valores reflejados** están siendo **unicode normalized** en el servidor (o en el cliente) y abusar de esta funcionalidad para evadir protecciones. [**Encuentra un ejemplo aquí**](../unicode-injection/index.html#xss-cross-site-scripting).
-### Bypass del flag PHP FILTER_VALIDATE_EMAIL
+### PHP FILTER_VALIDATE_EMAIL flag Bypass
```javascript
">