Translated ['src/pentesting-web/account-takeover.md'] to es

src/SUMMARY.md

@@ -842,7 +842,6 @@
   - [FISSURE - The RF Framework](todo/radio-hacking/fissure-the-rf-framework.md)
   - [Low-Power Wide Area Network](todo/radio-hacking/low-power-wide-area-network.md)
   - [Pentesting BLE - Bluetooth Low Energy](todo/radio-hacking/pentesting-ble-bluetooth-low-energy.md)
-- [Industrial Control Systems Hacking](todo/industrial-control-systems-hacking/README.md)
 - [Test LLMs](todo/test-llms.md)
 - [LLM Training](todo/llm-training-data-preparation/README.md)
   - [0. Basic LLM Concepts](todo/llm-training-data-preparation/0.-basic-llm-concepts.md)

src/pentesting-web/account-takeover.md

@@ -4,20 +4,20 @@
 
 ## **Problema de Autorización**
 
-Se debe intentar cambiar el correo electrónico de una cuenta, y el proceso de confirmación **debe ser examinado**. Si se encuentra **débil**, el correo electrónico debe ser cambiado al de la víctima prevista y luego confirmado.
+Se debe intentar cambiar el correo electrónico de una cuenta, y el proceso de confirmación **debe ser examinado**. Si se encuentra **débil**, el correo electrónico debe ser cambiado al del objetivo y luego confirmado.
 
 ## **Problema de Normalización de Unicode**
 
-1. La cuenta de la víctima prevista `victim@gmail.com`
+1. La cuenta del objetivo `victim@gmail.com`
-2. Se debe crear una cuenta utilizando Unicode\
+2. Se debe crear una cuenta usando Unicode\
 por ejemplo: `vićtim@gmail.com`
 
 Como se explicó en [**esta charla**](https://www.youtube.com/watch?v=CiIyaZ3x49c), el ataque anterior también podría realizarse abusando de proveedores de identidad de terceros:
 
-- Crear una cuenta en el proveedor de identidad de terceros con un correo electrónico similar al de la víctima utilizando algún carácter unicode (`vićtim@company.com`).
+- Crear una cuenta en el proveedor de identidad de terceros con un correo electrónico similar al del objetivo usando algún carácter unicode (`vićtim@company.com`).
 - El proveedor de terceros no debería verificar el correo electrónico.
-- Si el proveedor de identidad verifica el correo electrónico, tal vez puedas atacar la parte del dominio como: `victim@ćompany.com` y registrar ese dominio y esperar que el proveedor de identidad genere la versión ascii del dominio mientras la plataforma de la víctima normaliza el nombre de dominio.
+- Si el proveedor de identidad verifica el correo electrónico, tal vez puedas atacar la parte del dominio como: `victim@ćompany.com` y registrar ese dominio y esperar que el proveedor de identidad genere la versión ascii del dominio mientras la plataforma del objetivo normaliza el nombre de dominio.
-- Iniciar sesión a través de este proveedor de identidad en la plataforma de la víctima que debería normalizar el carácter unicode y permitirte acceder a la cuenta de la víctima.
+- Iniciar sesión a través de este proveedor de identidad en la plataforma del objetivo que debería normalizar el carácter unicode y permitirte acceder a la cuenta del objetivo.
 
 Para más detalles, consulta el documento sobre Normalización de Unicode:
 
@@ -25,15 +25,15 @@ Para más detalles, consulta el documento sobre Normalización de Unicode:
 unicode-injection/unicode-normalization.md
 {{#endref}}
 
-## **Reutilización de Token de Restablecimiento**
+## **Reutilización del Token de Restablecimiento**
 
 Si el sistema objetivo permite que el **enlace de restablecimiento sea reutilizado**, se deben hacer esfuerzos para **encontrar más enlaces de restablecimiento** utilizando herramientas como `gau`, `wayback` o `scan.io`.
 
 ## **Pre Toma de Control de Cuenta**
 
-1. Se debe usar el correo electrónico de la víctima para registrarse en la plataforma, y se debe establecer una contraseña (se debe intentar confirmarla, aunque la falta de acceso a los correos de la víctima podría hacer esto imposible).
+1. El correo electrónico del objetivo debe ser utilizado para registrarse en la plataforma, y se debe establecer una contraseña (se debe intentar confirmarla, aunque la falta de acceso a los correos del objetivo podría hacer esto imposible).
-2. Se debe esperar hasta que la víctima se registre usando OAuth y confirme la cuenta.
+2. Se debe esperar hasta que el objetivo se registre usando OAuth y confirme la cuenta.
-3. Se espera que el registro regular sea confirmado, permitiendo el acceso a la cuenta de la víctima.
+3. Se espera que el registro regular sea confirmado, permitiendo el acceso a la cuenta del objetivo.
 
 ## **Configuración Incorrecta de CORS para Toma de Control de Cuenta**
 
@@ -59,9 +59,9 @@ Si encuentras un XSS en la aplicación, podrías ser capaz de robar cookies, alm
 xss-cross-site-scripting/
 {{#endref}}
 
-## **Misma Origen + Cookies**
+## **Same Origin + Cookies**
 
-Si encuentras un XSS limitado o una toma de control de subdominio, podrías jugar con las cookies (fijándolas, por ejemplo) para intentar comprometer la cuenta de la víctima:
+Si encuentras un XSS limitado o una toma de control de subdominio, podrías jugar con las cookies (fijándolas, por ejemplo) para intentar comprometer la cuenta del objetivo:
 
 {{#ref}}
 hacking-with-cookies/
@@ -83,11 +83,11 @@ Si la respuesta de autenticación podría ser **reducida a un simple booleano, s
 oauth-to-account-takeover.md
 {{#endref}}
 
-## Inyección de Encabezado Host
+## Inyección de Cabecera Host
 
-1. El encabezado Host se modifica tras la iniciación de una solicitud de restablecimiento de contraseña.
+1. La cabecera Host se modifica tras la iniciación de una solicitud de restablecimiento de contraseña.
-2. El encabezado proxy `X-Forwarded-For` se altera a `attacker.com`.
+2. La cabecera proxy `X-Forwarded-For` se altera a `attacker.com`.
-3. Los encabezados Host, Referer y Origin se cambian simultáneamente a `attacker.com`.
+3. Las cabeceras Host, Referer y Origin se cambian simultáneamente a `attacker.com`.
 4. Después de iniciar un restablecimiento de contraseña y optar por reenviar el correo, se emplean los tres métodos mencionados anteriormente.
 
 ## Manipulación de Respuesta
@@ -104,13 +104,18 @@ Estas técnicas de manipulación son efectivas en escenarios donde se utiliza JS
 De [este informe](https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea):
 
 - El atacante solicita cambiar su correo electrónico por uno nuevo.
-- El atacante recibe un enlace para confirmar el cambio del correo electrónico.
+- El atacante recibe un enlace para confirmar el cambio de correo electrónico.
-- El atacante envía el enlace a la víctima para que lo haga clic.
+- El atacante envía el enlace al objetivo para que lo haga clic.
-- El correo electrónico de la víctima se cambia al indicado por el atacante.
+- El correo electrónico del objetivo se cambia al indicado por el atacante.
 - El atacante puede recuperar la contraseña y tomar el control de la cuenta.
 
 Esto también ocurrió en [**este informe**](https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea).
 
+### Bypass de verificación de correo electrónico para Toma de Control de Cuenta
+- El atacante inicia sesión con attacker@test.com y verifica el correo electrónico al registrarse.
+- El atacante cambia el correo electrónico verificado a victim@test.com (sin verificación secundaria en el cambio de correo electrónico).
+- Ahora el sitio web permite que victim@test.com inicie sesión y hemos eludido la verificación de correo electrónico del usuario objetivo.
+
 ### Cookies Antiguas
 
 Como se explicó [**en esta publicación**](https://medium.com/@niraj1mahajan/uncovering-the-hidden-vulnerability-how-i-found-an-authentication-bypass-on-shopifys-exchange-cc2729ea31a9), fue posible iniciar sesión en una cuenta, guardar las cookies como un usuario autenticado, cerrar sesión y luego iniciar sesión nuevamente.\