### **Scripts de Contenido**
-Cada script de contenido tiene acceso directo al DOM de una **única página web** y está expuesto a **entrada potencialmente maliciosa**. Sin embargo, el script de contenido no contiene permisos más allá de la capacidad de enviar mensajes al núcleo de la extensión.
+Cada script de contenido tiene acceso directo al DOM de una **única página web** y está expuesto a **posibles entradas maliciosas**. Sin embargo, el script de contenido no contiene permisos más allá de la capacidad de enviar mensajes al núcleo de la extensión.
### **Núcleo de la Extensión**
@@ -22,12 +22,12 @@ El núcleo de la extensión contiene la mayoría de los privilegios/accesos de l
### **Binario Nativo**
-La extensión permite un binario nativo que puede **acceder a la máquina host con todos los privilegios del usuario.** El binario nativo interactúa con el núcleo de la extensión a través de la interfaz de programación de aplicaciones de plugins de Netscape estándar ([NPAPI](https://en.wikipedia.org/wiki/NPAPI)) utilizada por Flash y otros complementos de navegador.
+La extensión permite un binario nativo que puede **acceder a la máquina host con los privilegios completos del usuario.** El binario nativo interactúa con el núcleo de la extensión a través de la interfaz de programación de aplicaciones de plugins de Netscape estándar ([NPAPI](https://en.wikipedia.org/wiki/NPAPI)) utilizada por Flash y otros complementos de navegador.
### Límites
> [!CAUTION]
-> Para obtener los privilegios completos del usuario, un atacante debe convencer a la extensión de pasar entrada maliciosa desde el script de contenido al núcleo de la extensión y desde el núcleo de la extensión al binario nativo.
+> Para obtener los privilegios completos del usuario, un atacante debe convencer a la extensión de pasar entradas maliciosas desde el script de contenido al núcleo de la extensión y desde el núcleo de la extensión al binario nativo.
Cada componente de la extensión está separado de los demás por **fuertes límites protectores**. Cada componente se ejecuta en un **proceso del sistema operativo separado**. Los scripts de contenido y los núcleos de extensión se ejecutan en **procesos de sandbox** no disponibles para la mayoría de los servicios del sistema operativo.
@@ -61,7 +61,7 @@ Ejemplo:
```
### `content_scripts`
-Los scripts de contenido se **cargan** cada vez que el usuario **navega a una página que coincide**, en nuestro caso, cualquier página que coincida con la expresión **`https://example.com/*`** y que no coincida con la regex **`*://*/*/business*`**. Se ejecutan **como los propios scripts de la página** y tienen acceso arbitrario al [Document Object Model (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) de la página.
+Los scripts de contenido se **cargan** cada vez que el usuario **navega a una página que coincide**, en nuestro caso, cualquier página que coincida con la expresión **`https://example.com/*`** y que no coincida con la regex **`*://*/*/business*`**. Se ejecutan **como los propios scripts de la página** y tienen acceso arbitrario al [Modelo de Objetos del Documento (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) de la página.
```json
"content_scripts": [
{
@@ -78,7 +78,7 @@ Los scripts de contenido se **cargan** cada vez que el usuario **navega a una p
```
Para incluir o excluir más URLs, también es posible usar **`include_globs`** y **`exclude_globs`**.
-Este es un ejemplo de script de contenido que añadirá un botón de explicación a la página cuando [la API de almacenamiento](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage) para recuperar el valor `message` del almacenamiento de la extensión.
+Este es un ejemplo de script de contenido que añadirá un botón de explicación a la página cuando [la API de almacenamiento](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage) para recuperar el valor de `message` del almacenamiento de la extensión.
```js
chrome.storage.local.get("message", (result) => {
let div = document.createElement("div")
@@ -104,7 +104,7 @@ Una vez que se muestran las herramientas de desarrollador, se debe hacer clic en
### Scripts de contenido inyectados
> [!TIP]
-> Tenga en cuenta que **los Scripts de Contenido no son obligatorios** ya que también es posible **inyectar dinámicamente** scripts y **inyectarlos programáticamente** en páginas web a través de **`tabs.executeScript`**. Esto proporciona en realidad más **controles granulares**.
+> Tenga en cuenta que **los Scripts de Contenido no son obligatorios** ya que también es posible **inyectar dinámicamente** scripts y **inyectarlos programáticamente** en páginas web a través de **`tabs.executeScript`**. Esto en realidad proporciona más **controles granulares**.
Para la inyección programática de un script de contenido, se requiere que la extensión tenga [permisos de host](https://developer.chrome.com/docs/extensions/reference/permissions) para la página en la que se van a inyectar los scripts. Estos permisos pueden asegurarse ya sea **solicitándolos** dentro del manifiesto de la extensión o de manera temporal a través de [**activeTab**](https://developer.chrome.com/docs/extensions/reference/manifest/activeTab).
@@ -243,7 +243,7 @@ Las extensiones de navegador pueden contener varios tipos de páginas:
-Ten en cuenta que estas páginas no son persistentes como las páginas de fondo, ya que cargan contenido dinámicamente según sea necesario. A pesar de esto, comparten ciertas capacidades con la página de fondo:
+Ten en cuenta que estas páginas no son persistentes como las páginas de fondo, ya que cargan contenido dinámicamente según la necesidad. A pesar de esto, comparten ciertas capacidades con la página de fondo:
- **Comunicación con Scripts de Contenido:** Similar a la página de fondo, estas páginas pueden recibir mensajes de scripts de contenido, facilitando la interacción dentro de la extensión.
- **Acceso a APIs Específicas de la Extensión:** Estas páginas disfrutan de acceso completo a APIs específicas de la extensión, sujeto a los permisos definidos para la extensión.
@@ -338,7 +338,7 @@ Según la [**documentación**](https://developer.chrome.com/docs/extensions/refe
Cuantas **menos extensiones y URLs** se indiquen aquí, **menor será la superficie de ataque**.
> [!CAUTION]
-> Si una página web **vulnerable a XSS o toma de control** se indica en **`externally_connectable`**, un atacante podrá **enviar mensajes directamente al script de fondo**, eludiendo completamente el Content Script y su CSP.
+> Si se indica una página web **vulnerable a XSS o toma de control** en **`externally_connectable`**, un atacante podrá **enviar mensajes directamente al script de fondo**, eludiendo completamente el Content Script y su CSP.
>
> Por lo tanto, este es un **bypass muy poderoso**.
>
@@ -352,7 +352,7 @@ Para comunicarse entre el script de contenido y la página web, generalmente se
### Dentro de la extensión
-Generalmente, se utiliza la función **`chrome.runtime.sendMessage`** para enviar un mensaje dentro de la extensión (generalmente manejado por el script `background`) y para recibirlo y manejarlo se declara un oyente llamando a **`chrome.runtime.onMessage.addListener`**.
+Generalmente se utiliza la función **`chrome.runtime.sendMessage`** para enviar un mensaje dentro de la extensión (generalmente manejado por el script `background`) y para recibir y manejarlo se declara un oyente llamando a **`chrome.runtime.onMessage.addListener`**.
También es posible usar **`chrome.runtime.connect()`** para tener una conexión persistente en lugar de enviar mensajes individuales, es posible usarlo para **enviar** y **recibir** **mensajes** como en el siguiente ejemplo:
@@ -401,7 +401,7 @@ Donde es necesario mencionar el **ID de la extensión**.
### Mensajería Nativa
-Es posible que los scripts de fondo se comuniquen con binarios dentro del sistema, lo que podría ser **propenso a vulnerabilidades críticas como RCEs** si esta comunicación no está debidamente asegurada. [More on this later](#native-messaging).
+Es posible que los scripts de fondo se comuniquen con binarios dentro del sistema, lo que podría ser **propenso a vulnerabilidades críticas como RCEs** si esta comunicación no está debidamente asegurada. [More on this later](./#native-messaging).
```javascript
chrome.runtime.sendNativeMessage(
"com.my_company.my_application",
@@ -458,7 +458,7 @@ Una comunicación segura de Post Message debe verificar la autenticidad del mens
- Si se utiliza una expresión regular, ten mucho cuidado.
- **Fuente**: `received_message.source !== window` se puede usar para verificar si el mensaje fue **desde la misma ventana** donde el Script de Contenido está escuchando.
-Las verificaciones anteriores, incluso si se realizan, podrían ser vulnerables, así que verifica en la siguiente página **potenciales bypasses de Post Message**:
+Las verificaciones anteriores, incluso si se realizan, podrían ser vulnerables, así que verifica en la siguiente página **posibles bypasses de Post Message**:
{{#ref}}
../postmessage-vulnerabilities/
@@ -527,7 +527,7 @@ Una consideración importante es que en escenarios donde múltiples páginas est
Al crear nuevas extensiones, la preferencia debe ser hacia promesas en lugar de callbacks. Con respecto al uso de callbacks, la función `sendResponse()` se considera válida solo si se ejecuta directamente dentro del contexto sincrónico, o si el controlador de eventos indica una operación asincrónica al devolver `true`. Si ninguno de los controladores devuelve `true` o si la función `sendResponse()` se elimina de la memoria (recolectada por el garbage collector), el callback asociado con la función `sendMessage()` se activará por defecto.
-## Mensajería Nativa
+## Native Messaging
Las extensiones del navegador también permiten comunicarse con **binarios en el sistema a través de stdin**. La aplicación debe instalar un json que lo indique en un json como:
```json
@@ -567,9 +567,9 @@ Y dentro de esto se explica un ejemplo de **cómo ir de cualquier página a RCE
## Información Sensible en Memoria/Código/Portapapeles
-Si una Extensión del Navegador almacena **información sensible dentro de su memoria**, esto podría ser **volcado** (especialmente en máquinas Windows) y **buscado** para esta información.
+Si una extensión del navegador almacena **información sensible dentro de su memoria**, esta podría ser **volcada** (especialmente en máquinas con Windows) y **buscada** para esta información.
-Por lo tanto, la memoria de la Extensión del Navegador **no debe considerarse segura** y **la información sensible** como credenciales o frases mnemotécnicas **no debe ser almacenada**.
+Por lo tanto, la memoria de la extensión del navegador **no debe considerarse segura** y **la información sensible** como credenciales o frases mnemotécnicas **no debe almacenarse**.
Por supuesto, no **coloque información sensible en el código**, ya que será **pública**.
@@ -579,8 +579,8 @@ Además, información altamente sensible como claves mnemotécnicas o contraseñ
## Cargando una Extensión en el Navegador
-1. **Descargue** la Extensión del Navegador y descomprímala.
-2. Vaya a **`chrome://extensions/`** y **active** el `Modo Desarrollador`.
+1. **Descargue** la extensión del navegador y descomprímala.
+2. Vaya a **`chrome://extensions/`** y **active** el `Modo de Desarrollador`.
3. Haga clic en el botón **`Cargar descomprimido`**.
En **Firefox**, vaya a **`about:debugging#/runtime/this-firefox`** y haga clic en el botón **`Cargar complemento temporal`**.
@@ -610,13 +610,13 @@ Otro método conveniente es usar el Chrome Extension Source Viewer, que es un pr
### Ver el código fuente de la extensión instalada localmente
-Las extensiones de Chrome instaladas localmente también se pueden inspeccionar. Así es como:
+Las extensiones de Chrome instaladas localmente también se pueden inspeccionar. Aquí te explicamos cómo:
1. Accede a tu directorio de perfil local de Chrome visitando `chrome://version/` y localizando el campo "Profile Path".
2. Navega a la subcarpeta `Extensions/` dentro del directorio del perfil.
3. Esta carpeta contiene todas las extensiones instaladas, típicamente con su código fuente en un formato legible.
-Para identificar extensiones, puedes mapear sus IDs a nombres:
+Para identificar las extensiones, puedes mapear sus IDs a nombres:
- Habilita el Modo Desarrollador en la página `about:extensions` para ver los IDs de cada extensión.
- Dentro de la carpeta de cada extensión, el archivo `manifest.json` contiene un campo `name` legible, ayudándote a identificar la extensión.
@@ -648,7 +648,7 @@ Aunque las extensiones de navegador tienen una **superficie de ataque limitada**
- [ ] **Limitar** tanto como sea posible los **`web_accessible_resources`**, incluso vacíos si es posible.
- [ ] Si **`web_accessible_resources`** no es ninguno, verificar [**ClickJacking**](browext-clickjacking.md)
- [ ] Si ocurre alguna **comunicación** de la **extensión** a la **página web**, [**verificar XSS**](browext-xss-example.md) **vulnerabilidades** causadas en la comunicación.
-- [ ] Si se utilizan Post Messages, verificar [**vulnerabilidades de Post Message**](../postmessage-vulnerabilities/index.html)**.**
+- [ ] Si se utilizan Post Messages, verificar [**vulnerabilidades de Post Message**](../postmessage-vulnerabilities/)**.**
- [ ] Si el **Content Script accede a detalles del DOM**, verificar que **no estén introduciendo un XSS** si son **modificados** por la web
- [ ] Hacer un énfasis especial si esta comunicación también está involucrada en la **comunicación de Content Script -> script de fondo**
- [ ] Si el script de fondo se comunica a través de **native messaging**, verificar que la comunicación sea segura y esté saneada
@@ -665,7 +665,7 @@ Aunque las extensiones de navegador tienen una **superficie de ataque limitada**
### [**Tarnish**](https://thehackerblog.com/tarnish/)
- Extrae cualquier extensión de Chrome de un enlace proporcionado de la tienda web de Chrome.
-- Visor de **manifest.json**: simplemente muestra una versión JSON formateada del manifiesto de la extensión.
+- Visor de **[**manifest.json**](https://developer.chrome.com/extensions/manifest)**: simplemente muestra una versión JSON formateada del manifiesto de la extensión.
- **Análisis de Huellas Dactilares**: Detección de [web_accessible_resources](https://developer.chrome.com/extensions/manifest/web_accessible_resources) y generación automática de JavaScript de huellas dactilares de extensiones de Chrome.
- **Análisis de Clickjacking Potencial**: Detección de páginas HTML de extensiones con la directiva [web_accessible_resources](https://developer.chrome.com/extensions/manifest/web_accessible_resources) establecida. Estas son potencialmente vulnerables a clickjacking dependiendo del propósito de las páginas.
- Visor de **Advertencias de Permisos**: que muestra una lista de todas las advertencias de permisos de Chrome que se mostrarán cuando un usuario intente instalar la extensión.
@@ -677,7 +677,7 @@ Aunque las extensiones de navegador tienen una **superficie de ataque limitada**
- Un botón "Ver Archivo" para ver el archivo fuente completo que contiene el código.
- La ruta del archivo alertado.
- La URI completa de la extensión de Chrome del archivo alertado.
-- El tipo de archivo que es, como un script de Página de Fondo, Script de Contenido, Acción de Navegador, etc.
+- El tipo de archivo que es, como un script de Página de Fondo, Script de Contenido, Acción del Navegador, etc.
- Si la línea vulnerable está en un archivo JavaScript, las rutas de todas las páginas donde está incluida, así como el tipo de estas páginas y el estado de [web_accessible_resource](https://developer.chrome.com/extensions/manifest/web_accessible_resources).
- **Analizador de Política de Seguridad de Contenido (CSP) y verificador de bypass**: Esto señalará debilidades en la CSP de su extensión y también iluminará cualquier forma potencial de eludir su CSP debido a CDNs en la lista blanca, etc.
- **Bibliotecas Conocidas Vulnerables**: Esto utiliza [Retire.js](https://retirejs.github.io/retire.js/) para verificar cualquier uso de bibliotecas JavaScript conocidas como vulnerables.
@@ -689,7 +689,7 @@ Aunque las extensiones de navegador tienen una **superficie de ataque limitada**
### [Neto](https://github.com/elevenpaths/neto)
-El proyecto Neto es un paquete de Python 3 concebido para analizar y desentrañar características ocultas de plugins y extensiones de navegador para navegadores bien conocidos como Firefox y Chrome. Automatiza el proceso de descomprimir los archivos empaquetados para extraer estas características de recursos relevantes en una extensión como `manifest.json`, carpetas de localización o archivos fuente de Javascript y HTML.
+El proyecto Neto es un paquete de Python 3 concebido para analizar y desentrañar características ocultas de los complementos y extensiones de navegador para navegadores bien conocidos como Firefox y Chrome. Automatiza el proceso de descomprimir los archivos empaquetados para extraer estas características de recursos relevantes en una extensión como `manifest.json`, carpetas de localización o archivos fuente de Javascript y HTML.
## Referencias
diff --git a/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md b/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md
index e545bfc28..d54fff40f 100644
--- a/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md
+++ b/src/pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md
@@ -32,7 +32,7 @@ En la extensión PrivacyBadger, se identificó una vulnerabilidad relacionada co
"icons/*"
]
```
-Esta configuración llevó a un posible problema de seguridad. Específicamente, el archivo `skin/popup.html`, que se renderiza al interactuar con el ícono de PrivacyBadger en el navegador, podría ser incrustado dentro de un `iframe`. Esta incrustación podría ser explotada para engañar a los usuarios haciéndoles clic inadvertidamente en "Desactivar PrivacyBadger para este sitio web". Tal acción comprometería la privacidad del usuario al desactivar la protección de PrivacyBadger y potencialmente someter al usuario a un mayor seguimiento. Una demostración visual de esta explotación se puede ver en un ejemplo de video de ClickJacking proporcionado en [**https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm**](https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm).
+Esta configuración llevó a un posible problema de seguridad. Específicamente, el archivo `skin/popup.html`, que se renderiza al interactuar con el ícono de PrivacyBadger en el navegador, podría ser incrustado dentro de un `iframe`. Esta incrustación podría ser explotada para engañar a los usuarios y hacer que hagan clic inadvertidamente en "Desactivar PrivacyBadger para este sitio web". Tal acción comprometería la privacidad del usuario al desactivar la protección de PrivacyBadger y potencialmente someter al usuario a un mayor seguimiento. Una demostración visual de esta explotación se puede ver en un ejemplo de video de ClickJacking proporcionado en [**https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm**](https://blog.lizzie.io/clickjacking-privacy-badger/badger-fade.webm).
Para abordar esta vulnerabilidad, se implementó una solución sencilla: la eliminación de `/skin/*` de la lista de `web_accessible_resources`. Este cambio mitigó efectivamente el riesgo al asegurar que el contenido del directorio `skin/` no pudiera ser accedido o manipulado a través de recursos accesibles por la web.
diff --git a/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md b/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md
index 23c384c9d..96e519375 100644
--- a/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md
+++ b/src/pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md
@@ -37,13 +37,13 @@ Los siguientes `host_permissions` permiten básicamente todos los web:
""
]
```
-Estos son los hosts a los que la extensión del navegador puede acceder libremente. Esto se debe a que cuando una extensión del navegador llama a **`fetch("https://gmail.com/")`** no está restringida por CORS.
+Estos son los hosts a los que la extensión del navegador puede acceder libremente. Esto se debe a que cuando una extensión del navegador llama a **`fetch("https://gmail.com/")`**, no está restringida por CORS.
## Abusando de `permissions` y `host_permissions`
### Pestañas
-Además, **`host_permissions`** también desbloquea la funcionalidad “avanzada” de la [**API de pestañas**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs). Permiten que la extensión llame a [tabs.query()](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/query) y no solo obtenga una **lista de las pestañas del navegador del usuario**, sino que también aprenda qué **página web (es decir, dirección y título) está cargada**.
+Además, **`host_permissions`** también desbloquea la funcionalidad “avanzada” de la [**API de pestañas**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs). Permiten que la extensión llame a [tabs.query()](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/query) y no solo obtenga una **lista de las pestañas del navegador del usuario**, sino también averigüe qué **página web (es decir, dirección y título) está cargada**.
> [!CAUTION]
> No solo eso, los oyentes como [**tabs.onUpdated**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/onUpdated) **también se vuelven mucho más útiles**. Estos serán notificados cada vez que se cargue una nueva página en una pestaña.
@@ -55,7 +55,7 @@ Los scripts de contenido no necesariamente están escritos de forma estática en
Ambas API permiten ejecutar no solo archivos contenidos en las extensiones como scripts de contenido, sino también **código arbitrario**. La primera permite pasar código JavaScript como una cadena, mientras que la segunda espera una función de JavaScript que es menos propensa a vulnerabilidades de inyección. Aún así, ambas API causarán estragos si se usan incorrectamente.
> [!CAUTION]
-> Además de las capacidades anteriores, los scripts de contenido podrían, por ejemplo, **interceptar credenciales** a medida que se ingresan en las páginas web. Otra forma clásica de abusar de ellos es **inyectar publicidad** en cada sitio web. También es posible agregar **mensajes de estafa** para abusar de la credibilidad de los sitios de noticias. Finalmente, podrían **manipular sitios web bancarios** para redirigir transferencias de dinero.
+> Además de las capacidades anteriores, los scripts de contenido podrían, por ejemplo, **interceptar credenciales** a medida que se ingresan en las páginas web. Otra forma clásica de abusar de ellos es **inyectar publicidad** en cada sitio web. Agregar **mensajes de estafa** para abusar de la credibilidad de los sitios de noticias también es posible. Finalmente, podrían **manipular sitios web bancarios** para redirigir transferencias de dinero.
### Privilegios implícitos
@@ -72,14 +72,14 @@ Si revisas los posibles parámetros de `tabs.create()`, también notarás que su
### Webcam, geolocalización y amigos
-Probablemente sepas que los sitios web pueden solicitar permisos especiales, por ejemplo, para acceder a tu cámara web (herramientas de videoconferencia) o ubicación geográfica (mapas). Son características con un considerable potencial de abuso, por lo que los usuarios deben confirmar cada vez que aún desean esto.
+Probablemente sepas que los sitios web pueden solicitar permisos especiales, por ejemplo, para acceder a tu webcam (herramientas de videoconferencia) o ubicación geográfica (mapas). Son características con un considerable potencial de abuso, por lo que los usuarios deben confirmar cada vez que aún desean esto.
> [!CAUTION]
-> No es así con las extensiones del navegador. **Si una extensión del navegador** [**quiere acceso a tu cámara web o micrófono**](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia)**, solo necesita pedir permiso una vez**
+> No es así con las extensiones del navegador. **Si una extensión del navegador** [**quiere acceso a tu webcam o micrófono**](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia)**, solo necesita pedir permiso una vez**
-Típicamente, una extensión lo hará inmediatamente después de ser instalada. Una vez que se acepta este aviso, **el acceso a la cámara web es posible en cualquier momento**, incluso si el usuario no está interactuando con la extensión en ese momento. Sí, un usuario solo aceptará este aviso si la extensión realmente necesita acceso a la cámara web. Pero después de eso, deben confiar en que la extensión no grabará nada en secreto.
+Típicamente, una extensión lo hará inmediatamente después de ser instalada. Una vez que se acepta este aviso, **el acceso a la webcam es posible en cualquier momento**, incluso si el usuario no está interactuando con la extensión en ese momento. Sí, un usuario solo aceptará este aviso si la extensión realmente necesita acceso a la webcam. Pero después de eso, deben confiar en que la extensión no grabará nada en secreto.
-Con acceso a [tu ubicación geográfica exacta](https://developer.mozilla.org/en-US/docs/Web/API/Geolocation) o [contenidos de tu portapapeles](https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API), otorgar permiso explícitamente es innecesario por completo. **Una extensión simplemente agrega `geolocation` o `clipboard` a la** [**entrada de permisos**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) **de su manifiesto**. Estos privilegios de acceso se otorgan implícitamente cuando se instala la extensión. Así que una extensión maliciosa o comprometida con estos privilegios puede crear tu perfil de movimiento o monitorear tu portapapeles en busca de contraseñas copiadas sin que te des cuenta.
+Con acceso a [tu ubicación geográfica exacta](https://developer.mozilla.org/en-US/docs/Web/API/Geolocation) o [el contenido de tu portapapeles](https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API), otorgar permiso explícitamente es innecesario por completo. **Una extensión simplemente agrega `geolocation` o `clipboard` a la** [**entrada de permisos**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) **de su manifiesto**. Estos privilegios de acceso se otorgan implícitamente cuando se instala la extensión. Así que una extensión maliciosa o comprometida con estos privilegios puede crear tu perfil de movimiento o monitorear tu portapapeles en busca de contraseñas copiadas sin que te des cuenta.
Agregar la palabra clave **`history`** a la [entrada de permisos](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) del manifiesto de la extensión otorga **acceso a la** [**API de historial**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/history). Permite recuperar todo el historial de navegación del usuario de una vez, sin esperar a que el usuario visite estos sitios web nuevamente.
@@ -99,7 +99,7 @@ Puedes encontrar la [**lista completa de permisos que una extensión de navegado
La política del desarrollador de Google prohíbe explícitamente a las extensiones solicitar más privilegios de los necesarios para su funcionalidad, mitigando efectivamente las solicitudes excesivas de permisos. Un caso en el que una extensión del navegador sobrepasó este límite involucró su distribución con el propio navegador en lugar de a través de una tienda de complementos.
-Los navegadores podrían limitar aún más el abuso de los privilegios de extensión. Por ejemplo, las API [tabCapture](https://developer.chrome.com/docs/extensions/reference/tabCapture/) y [desktopCapture](https://developer.chrome.com/docs/extensions/reference/desktopCapture/) de Chrome, utilizadas para la grabación de pantalla, están diseñadas para minimizar el abuso. La API tabCapture solo puede ser activada a través de la interacción directa del usuario, como hacer clic en el ícono de la extensión, mientras que desktopCapture requiere la confirmación del usuario para que la ventana sea grabada, previniendo actividades de grabación clandestinas.
+Los navegadores podrían limitar aún más el abuso de los privilegios de extensión. Por ejemplo, las API [tabCapture](https://developer.chrome.com/docs/extensions/reference/tabCapture/) y [desktopCapture](https://developer.chrome.com/docs/extensions/reference/desktopCapture/) de Chrome, utilizadas para la grabación de pantalla, están diseñadas para minimizar el abuso. La API tabCapture solo puede ser activada a través de la interacción directa del usuario, como hacer clic en el ícono de la extensión, mientras que desktopCapture requiere confirmación del usuario para que la ventana sea grabada, previniendo actividades de grabación clandestinas.
Sin embargo, endurecer las medidas de seguridad a menudo resulta en una disminución de la flexibilidad y la facilidad de uso de las extensiones. El [permiso activeTab](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#activetab_permission) ilustra este compromiso. Se introdujo para eliminar la necesidad de que las extensiones solicitaran privilegios de host en toda la internet, permitiendo que las extensiones accedan solo a la pestaña actual tras la activación explícita por parte del usuario. Este modelo es efectivo para extensiones que requieren acciones iniciadas por el usuario, pero no es suficiente para aquellas que requieren acciones automáticas o preventivas, comprometiendo así la conveniencia y la capacidad de respuesta inmediata.
diff --git a/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md b/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md
index 09e333816..e02edf373 100644
--- a/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md
+++ b/src/pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md
@@ -40,7 +40,7 @@ let maliciousURL = `${baseURL}?content=${encodeURIComponent(xssPayload)}`
document.querySelector("iframe").src = maliciousURL
}, 1000)
```
-Una Política de Seguridad de Contenido demasiado permisiva como:
+Una Política de Seguridad de Contenido (Content Security Policy) demasiado permisiva como:
```json
"content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self';"
```
@@ -54,7 +54,7 @@ newFrame.src =
encodeURIComponent("")
document.body.append(newFrame)
```
-## XSS basado en DOM + ClickJacking
+## DOM-based XSS + ClickJacking
Este ejemplo fue tomado de la [publicación original](https://thehackerblog.com/steam-fire-and-paste-a-story-of-uxss-via-dom-xss-clickjacking-in-steam-inventory-helper/).
@@ -84,7 +84,7 @@ Normalmente, la Política de Seguridad de Contenidos (CSP) de la extensión de C
Si bien esta vulnerabilidad es significativa, su explotación generalmente depende de la interacción del usuario: visitar la página, ingresar una carga útil de XSS y activar el botón “Agregar”.
-Para mejorar esta vulnerabilidad, se explota una vulnerabilidad secundaria de **clickjacking**. El manifiesto de la extensión de Chrome muestra una política extensa de `web_accessible_resources`:
+Para mejorar esta vulnerabilidad, se explota una vulnerabilidad secundaria de **clickjacking**. El manifiesto de la extensión de Chrome muestra una extensa política de `web_accessible_resources`:
```json
"web_accessible_resources": [
"html/bookmarks.html",
diff --git a/src/pentesting-web/cache-deception/README.md b/src/pentesting-web/cache-deception/README.md
index 3e8f5253d..63e713a99 100644
--- a/src/pentesting-web/cache-deception/README.md
+++ b/src/pentesting-web/cache-deception/README.md
@@ -52,7 +52,7 @@ Una vez que hayas **identificado** la **página** que puede ser abusada, qué **
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.
@@ -89,7 +89,7 @@ Note que si la cookie vulnerable es muy utilizada por los usuarios, las solicitu
### Generando discrepancias con delimitadores, normalización y puntos
-Verifique:
+Ver:
{{#ref}}
cache-poisoning-via-url-discrepancies.md
@@ -107,7 +107,7 @@ cache-poisoning-via-url-discrepancies.md
### Usando múltiples encabezados para explotar vulnerabilidades de envenenamiento de caché web
-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 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 hacia dónde se apunta la página por el redireccionamiento.
```markup
GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
@@ -116,7 +116,7 @@ X-Forwarded-Scheme: http
```
### Explotando con un encabezado `Vary` limitado
-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:
+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:
```markup
GET / HTTP/1.1
Host: vulnerbale.net
@@ -125,7 +125,7 @@ X-Host: attacker.com
```
### Fat Get
-Envía una solicitud GET con la solicitud en la URL y en el cuerpo. Si el servidor web utiliza la del cuerpo pero el servidor de caché almacena la de la URL, cualquier persona que acceda a esa URL utilizará en realidad el parámetro del cuerpo. Como la vulnerabilidad que James Kettle encontró en el sitio web de Github:
+Envía una solicitud GET con la solicitud en la URL y en el cuerpo. Si el servidor web utiliza la del cuerpo pero el servidor de caché almacena en caché la de la URL, cualquier persona que acceda a esa URL utilizará en realidad el parámetro del cuerpo. Como la vulnerabilidad que James Kettle encontró en el sitio web de Github:
```
GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
@@ -138,17 +138,17 @@ 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 no clave dentro de los parámetros 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 sin clave dentro de los que tienen 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
-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 del HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning).
-### Pruebas Automatizadas para Cache Poisoning
+### Pruebas automatizadas para la Poisoning de Caché Web
-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.
+El [Escáner de Vulnerabilidades de Caché Web](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.
Ejemplo de uso: `wcvs -u example.com`
@@ -164,19 +164,19 @@ Enviar un valor incorrecto en el encabezado content-type activó una respuesta 4
### GitLab + GCP CP-DoS
-GitLab utiliza buckets de GCP para almacenar contenido estático. **GCP Buckets** soporta el **encabezado `x-http-method-override`**. Por lo tanto, era posible enviar el encabezado `x-http-method-override: HEAD` y envenenar la caché para que devolviera un cuerpo de respuesta vacío. También podría soportar el método `PURGE`.
+GitLab utiliza buckets de GCP para almacenar contenido estático. **Los Buckets de GCP** soportan el **encabezado `x-http-method-override`**. Así que era posible enviar el encabezado `x-http-method-override: HEAD` y envenenar la caché para que devolviera un cuerpo de respuesta vacío. También podría soportar el método `PURGE`.
-### Rack Middleware (Ruby on Rails)
+### Middleware Rack (Ruby on Rails)
-En aplicaciones Ruby on Rails, a menudo se utiliza Rack middleware. El propósito del código Rack es tomar el valor del encabezado **`x-forwarded-scheme`** y establecerlo como el esquema de la solicitud. Cuando se envía el encabezado `x-forwarded-scheme: http`, ocurre una redirección 301 a la misma ubicación, lo que puede causar una Denegación de Servicio (DoS) a ese recurso. Además, la aplicación podría reconocer el encabezado `X-forwarded-host` y redirigir a los usuarios al host especificado. Este comportamiento puede llevar a la carga de archivos JavaScript desde el servidor de un atacante, lo que representa un riesgo de seguridad.
+En aplicaciones Ruby on Rails, a menudo se utiliza middleware Rack. El propósito del código Rack es tomar el valor del encabezado **`x-forwarded-scheme`** y establecerlo como el esquema de la solicitud. Cuando se envía el encabezado `x-forwarded-scheme: http`, ocurre una redirección 301 a la misma ubicación, lo que puede causar una Denegación de Servicio (DoS) a ese recurso. Además, la aplicación podría reconocer el encabezado `X-forwarded-host` y redirigir a los usuarios al host especificado. Este comportamiento puede llevar a la carga de archivos JavaScript desde el servidor de un atacante, lo que representa un riesgo de seguridad.
### 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 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 de 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 era almacenable 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 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é.
### Reglas de User Agent
@@ -184,7 +184,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 era almacenable 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 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é.
### Encontrando nuevos encabezados
@@ -192,9 +192,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 **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:
@@ -211,11 +211,11 @@ Luego, el **atacante** puede acceder a _http://www.example.com/home.php/non-exis
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 del HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception).
## Herramientas Automáticas
-- [**toxicache**](https://github.com/xhzeem/toxicache): escáner de Golang para encontrar vulnerabilidades de poisoning de caché web en una lista de URLs y probar múltiples técnicas de inyección.
+- [**toxicache**](https://github.com/xhzeem/toxicache): Escáner de Golang para encontrar vulnerabilidades de poisoning de caché web en una lista de URLs y probar múltiples técnicas de inyección.
## Referencias
diff --git a/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md b/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md
index fa49edaeb..1f67e44f4 100644
--- a/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md
+++ b/src/pentesting-web/cache-deception/cache-poisoning-to-dos.md
@@ -13,7 +13,7 @@ GET / HTTP/1.1
Host: redacted.com
X-Oversize-Hedear:Big-Value-000000000000000
```
-- **HTTP Meta Character (HMC) y valores inesperados**
+- **HTTP Meta Character (HMC) & Valores inesperados**
Envía un encabezado que contenga algunos **caracteres meta dañinos** como y . Para que el ataque funcione, primero debes eludir la caché.
```
@@ -92,7 +92,7 @@ Not Found
```
- **Normalización de rutas**
-Algunas páginas devolverán códigos de error enviando datos URLencode en la ruta, sin embargo, el servidor de caché URLdecode la ruta y almacena la respuesta para la ruta URLdecoded:
+Algunas páginas devolverán códigos de error al enviar datos URLencode en la ruta, sin embargo, el servidor de caché URLdecodeará la ruta y almacenará la respuesta para la ruta URLdecoded:
```
GET /api/v1%2e1/user HTTP/1.1
Host: redacted.com
diff --git a/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md b/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md
index fcc7b7c61..f7b888925 100644
--- a/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md
+++ b/src/pentesting-web/cache-deception/cache-poisoning-via-url-discrepancies.md
@@ -5,7 +5,7 @@
Este es un resumen de las técnicas propuestas en el post [https://portswigger.net/research/gotta-cache-em-all](https://portswigger.net/research/gotta-cache-em-all) para realizar ataques de cache poisoning **abusando de las discrepancias entre los proxies de caché y los servidores web.**
> [!NOTE]
-> El objetivo de este ataque es **hacer que el servidor de caché piense que se está cargando un recurso estático** para que lo almacene en caché, mientras que el servidor de caché guarda como clave de caché parte de la ruta, pero el servidor web responde resolviendo otra ruta. El servidor web resolverá la ruta real que cargará una página dinámica (que podría almacenar información sensible sobre el usuario, una carga maliciosa como XSS o redirigir para cargar un archivo JS desde el sitio web del atacante, por ejemplo).
+> El objetivo de este ataque es **hacer que el servidor de caché piense que se está cargando un recurso estático** para que lo almacene en caché, mientras que el servidor de caché almacena como clave de caché parte de la ruta, pero el servidor web responde resolviendo otra ruta. El servidor web resolverá la ruta real que cargará una página dinámica (que podría almacenar información sensible sobre el usuario, una carga maliciosa como XSS o redirigir para cargar un archivo JS desde el sitio web del atacante, por ejemplo).
## Delimitadores
@@ -18,13 +18,13 @@ Este es un resumen de las técnicas propuestas en el post [https://portswigger.n
Otros delimitadores específicos pueden encontrarse siguiendo este proceso:
-- **Paso 1**: Identificar solicitudes no cacheables y usarlas para monitorear cómo se manejan las URLs con posibles delimitadores.
+- **Paso 1**: Identificar solicitudes no cacheables y usarlas para monitorear cómo se manejan las URL con posibles delimitadores.
- **Paso 2**: Agregar sufijos aleatorios a las rutas y comparar la respuesta del servidor para determinar si un carácter funciona como delimitador.
-- **Paso 3**: Introducir delimitadores potenciales antes del sufijo aleatorio para ver si la respuesta cambia, indicando el uso de delimitadores.
+- **Paso 3**: Introducir posibles delimitadores antes del sufijo aleatorio para ver si la respuesta cambia, indicando el uso de delimitadores.
## Normalización y codificaciones
-- **Propósito**: Los analizadores de URL en los servidores de caché y de origen normalizan las URLs para extraer rutas para el mapeo de puntos finales y claves de caché.
+- **Propósito**: Los analizadores de URL en los servidores de caché y de origen normalizan las URL para extraer rutas para el mapeo de puntos finales y claves de caché.
- **Proceso**: Identifica delimitadores de ruta, extrae y normaliza la ruta decodificando caracteres y eliminando segmentos de punto.
### **Codificaciones**
@@ -35,7 +35,7 @@ Una forma de verificar estas inconsistencias es enviar solicitudes codificando d
### Segmento de punto
-La normalización de la ruta donde están involucrados los puntos también es muy interesante para los ataques de cache poisoning. Por ejemplo, `/static/../home/index` o `/aaa..\home/index`, algunos servidores de caché almacenarán en caché estas rutas con ellas mismas como claves, mientras que otros podrían resolver la ruta y usar `/home/index` como la clave de caché.\
+La normalización de la ruta donde están involucrados los puntos también es muy interesante para los ataques de cache poisoning. Por ejemplo, `/static/../home/index` o `/aaa..\home/index`, algunos servidores de caché almacenarán en caché estas rutas con ellas mismas como claves, mientras que otros podrían resolver la ruta y usar `/home/index` como clave de caché.\
Al igual que antes, enviar este tipo de solicitudes y verificar si la respuesta se obtuvo de la caché ayuda a identificar si la respuesta a `/home/index` es la respuesta enviada cuando se solicitan esas rutas.
## Recursos estáticos
@@ -47,6 +47,6 @@ Varios servidores de caché siempre almacenarán en caché una respuesta si se i
- **Directorios estáticos bien conocidos**: Los siguientes directorios contienen archivos estáticos y, por lo tanto, su respuesta debería ser almacenada en caché: /static, /assets, /wp-content, /media, /templates, /public, /shared
- Es posible forzar a un caché a almacenar una respuesta dinámica utilizando un delimitador, un directorio estático y puntos como: `/home/..%2fstatic/something` almacenará en caché `/static/something` y la respuesta será `/home`
- **Directorios estáticos + puntos**: Una solicitud a `/static/..%2Fhome` o a `/static/..%5Chome` podría ser almacenada en caché tal cual, pero la respuesta podría ser `/home`
-- **Archivos estáticos:** Algunos archivos específicos siempre se almacenan en caché como `/robots.txt`, `/favicon.ico`, y `/index.html`. Lo que se puede abusar como `/home/..%2Frobots.txt` donde la caché podría almacenar `/robots.txt` y el servidor de origen responder a `/home`.
+- **Archivos estáticos:** Algunos archivos específicos siempre se almacenan en caché, como `/robots.txt`, `/favicon.ico` y `/index.html`. Lo que se puede abusar como `/home/..%2Frobots.txt` donde la caché podría almacenar `/robots.txt` y el servidor de origen responder a `/home`.
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-web/content-security-policy-csp-bypass/README.md b/src/pentesting-web/content-security-policy-csp-bypass/README.md
index 6f3552b54..be973c043 100644
--- a/src/pentesting-web/content-security-policy-csp-bypass/README.md
+++ b/src/pentesting-web/content-security-policy-csp-bypass/README.md
@@ -18,10 +18,10 @@ Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com;
```
### Headers
-CSP se puede hacer cumplir o monitorear utilizando estos encabezados:
+CSP puede ser aplicado o monitoreado usando estos encabezados:
-- `Content-Security-Policy`: Hace cumplir la CSP; el navegador bloquea cualquier violación.
-- `Content-Security-Policy-Report-Only`: Se utiliza para monitoreo; informa violaciones sin bloquearlas. Ideal para pruebas en entornos de preproducción.
+- `Content-Security-Policy`: Aplica la CSP; el navegador bloquea cualquier violación.
+- `Content-Security-Policy-Report-Only`: Usado para monitoreo; informa violaciones sin bloquearlas. Ideal para pruebas en entornos de pre-producción.
### Defining Resources
@@ -53,7 +53,7 @@ object-src 'none';
- **base-uri**: Especifica las URLs permitidas para cargar usando elementos ``.
- **form-action**: Enumera los puntos finales válidos para envíos de formularios.
- **plugin-types**: Restringe los tipos MIME que una página puede invocar.
-- **upgrade-insecure-requests**: Instruye a los navegadores a reescribir URLs HTTP a HTTPS.
+- **upgrade-insecure-requests**: Indica a los navegadores que reescriban las URLs HTTP a HTTPS.
- **sandbox**: Aplica restricciones similares al atributo sandbox de un `