mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/external-recon-meth
This commit is contained in:
Translator
parent
dec87267bc
commit
4a04fdbe8b
@ -2,18 +2,13 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
Ahora que hemos construido la lista de activos de nuestro alcance, es hora de buscar algunos frutos bajos de OSINT.
|
||||
|
||||
### Plataformas que ya buscaron filtraciones
|
||||
|
||||
- [https://trufflesecurity.com/blog/introducing-forager/](https://trufflesecurity.com/blog/introducing-forager/)
|
||||
|
||||
### Filtraciones de claves API en github
|
||||
### Herramientas para encontrar secretos en repositorios de git y sistemas de archivos
|
||||
|
||||
- [https://github.com/dxa4481/truffleHog](https://github.com/dxa4481/truffleHog)
|
||||
- [https://github.com/gitleaks/gitleaks](https://github.com/gitleaks/gitleaks)
|
||||
- [https://github.com/praetorian-inc/noseyparker](https://github.com/praetorian-inc/noseyparker)
|
||||
- [https://github.com/GitGuardian/ggshield](https://github.com/GitGuardian/ggshield)
|
||||
- [https://github.com/JaimePolop/RExpository](https://github.com/JaimePolop/RExpository)
|
||||
- [https://github.com/Yelp/detect-secrets](https://github.com/Yelp/detect-secrets)
|
||||
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber)
|
||||
- [https://github.com/eth0izzle/shhgit](https://github.com/eth0izzle/shhgit)
|
||||
|
||||
@ -44,13 +44,13 @@ https://socialmedia.com/auth
|
||||
```
|
||||
https://example.com?code=uniqueCode123&state=randomString123
|
||||
```
|
||||
5. https://example.com utiliza este `code`, junto con su `client_id` y `client_secret`, para hacer una solicitud del lado del servidor para obtener un `access_token` en tu nombre, lo que permite el acceso a los permisos a los que diste tu consentimiento:
|
||||
5. https://example.com utiliza este `code`, junto con su `client_id` y `client_secret`, para hacer una solicitud del lado del servidor para obtener un `access_token` en su nombre, lo que permite el acceso a los permisos a los que usted consintió:
|
||||
```
|
||||
POST /oauth/access_token
|
||||
Host: socialmedia.com
|
||||
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
|
||||
```
|
||||
6. Finalmente, el proceso concluye cuando https://example.com emplea tu `access_token` para hacer una llamada API a Social Media para acceder
|
||||
6. Finalmente, el proceso concluye cuando https://example.com emplea tu `access_token` para hacer una llamada a la API de Social Media para acceder
|
||||
|
||||
## Vulnerabilidades <a href="#id-323a" id="id-323a"></a>
|
||||
|
||||
@ -66,15 +66,15 @@ Para aquellos que apuntan a un servidor OpenID, el punto final de descubrimiento
|
||||
|
||||
### XSS en la implementación de redirección <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Como se menciona en este informe de recompensas por errores [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html), podría ser posible que la **URL de redirección se esté reflejando en la respuesta** del servidor después de que el usuario se autentique, siendo **vulnerable a XSS**. Carga útil posible para probar:
|
||||
Como se menciona en este informe de recompensas por errores [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html), podría ser posible que la **URL de redirección se esté reflejando en la respuesta** del servidor después de que el usuario se autentica, siendo **vulnerable a XSS**. Carga útil posible para probar:
|
||||
```
|
||||
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
|
||||
```
|
||||
### CSRF - Manejo inadecuado del parámetro de estado <a href="#bda5" id="bda5"></a>
|
||||
|
||||
En las implementaciones de OAuth, el uso indebido u omisión del **`state` parameter** puede aumentar significativamente el riesgo de ataques de **Cross-Site Request Forgery (CSRF)**. Esta vulnerabilidad surge cuando el parámetro `state` es **no utilizado, utilizado como un valor estático o no validado adecuadamente**, permitiendo a los atacantes eludir las protecciones CSRF.
|
||||
En las implementaciones de OAuth, el uso indebido u omisión del **`state` parameter** puede aumentar significativamente el riesgo de ataques de **Cross-Site Request Forgery (CSRF)**. Esta vulnerabilidad surge cuando el parámetro `state` es **no utilizado, utilizado como un valor estático, o no validado o asociado correctamente con la sesión del usuario** durante el inicio de sesión, permitiendo a los atacantes eludir las protecciones CSRF.
|
||||
|
||||
Los atacantes pueden explotar esto interceptando el proceso de autorización para vincular su cuenta con la cuenta de una víctima, lo que lleva a posibles **tomas de control de cuentas**. Esto es especialmente crítico en aplicaciones donde se utiliza OAuth para **fines de autenticación**.
|
||||
Los atacantes pueden explotar esto interceptando el proceso de autorización para vincular su cuenta con la cuenta de una víctima, lo que lleva a posibles **tomas de control de cuentas** al hacer que un usuario inicie sesión con un flujo oauth casi finalizado que pertenece al atacante. Esto es especialmente crítico en aplicaciones donde se utiliza OAuth para **fines de autenticación**.
|
||||
|
||||
Se han documentado ejemplos del mundo real de esta vulnerabilidad en varios **CTF challenges** y **plataformas de hacking**, destacando sus implicaciones prácticas. El problema también se extiende a integraciones con servicios de terceros como **Slack**, **Stripe** y **PayPal**, donde los atacantes pueden redirigir notificaciones o pagos a sus cuentas.
|
||||
|
||||
@ -87,7 +87,7 @@ El manejo y validación adecuados del **`state` parameter** son cruciales para p
|
||||
|
||||
### Divulgación de Secretos <a href="#e177" id="e177"></a>
|
||||
|
||||
Identificar y proteger los parámetros secretos de OAuth es crucial. Mientras que el **`client_id`** puede ser divulgado de manera segura, revelar el **`client_secret`** presenta riesgos significativos. Si el `client_secret` se ve comprometido, los atacantes pueden explotar la identidad y confianza de la aplicación para **robar `access_tokens` de usuario** e información privada.
|
||||
Identificar y proteger los parámetros secretos de OAuth es crucial. Mientras que el **`client_id`** puede ser divulgado de manera segura, revelar el **`client_secret`** presenta riesgos significativos. Si el `client_secret` se ve comprometido, los atacantes pueden explotar la identidad y confianza de la aplicación para **robar `access_tokens` de usuarios** e información privada.
|
||||
|
||||
Una vulnerabilidad común surge cuando las aplicaciones manejan erróneamente el intercambio del `code` de autorización por un `access_token` del lado del cliente en lugar del lado del servidor. Este error lleva a la exposición del `client_secret`, permitiendo a los atacantes generar `access_tokens` bajo la apariencia de la aplicación. Además, a través de ingeniería social, los atacantes podrían escalar privilegios al agregar ámbitos adicionales a la autorización de OAuth, explotando aún más el estatus de confianza de la aplicación.
|
||||
|
||||
@ -126,7 +126,7 @@ Si puedes obtener el **código de autorización y usarlo con un cliente diferent
|
||||
|
||||
### AWS Cognito <a href="#bda5" id="bda5"></a>
|
||||
|
||||
En este informe de bug bounty: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) puedes ver que el **token** que **AWS Cognito** devuelve al usuario podría tener **suficientes permisos para sobrescribir los datos del usuario**. Por lo tanto, si puedes **cambiar el correo electrónico del usuario por otro correo electrónico**, podrías ser capaz de **tomar el control** de otras cuentas.
|
||||
En este informe de bug bounty: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) puedes ver que el **token** que **AWS Cognito** devuelve al usuario podría tener **suficientes permisos para sobrescribir los datos del usuario**. Por lo tanto, si puedes **cambiar el correo electrónico del usuario por un correo electrónico de otro usuario**, podrías ser capaz de **tomar el control** de otras cuentas.
|
||||
```bash
|
||||
# Read info of the user
|
||||
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]
|
||||
@ -153,7 +153,7 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat
|
||||
|
||||
Como [**se menciona en este informe**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), los flujos de OAuth que esperan recibir el **token** (y no un código) podrían ser vulnerables si no verifican que el token pertenece a la aplicación.
|
||||
|
||||
Esto se debe a que un **atacante** podría crear una **aplicación que soporte OAuth y login con Facebook** (por ejemplo) en su propia aplicación. Luego, una vez que una víctima inicie sesión con Facebook en la **aplicación del atacante**, el atacante podría obtener el **token OAuth del usuario otorgado a su aplicación y usarlo para iniciar sesión en la aplicación OAuth de la víctima usando el token de usuario de la víctima**.
|
||||
Esto se debe a que un **atacante** podría crear una **aplicación que soporte OAuth y login con Facebook** (por ejemplo) en su propia aplicación. Luego, una vez que una víctima inicia sesión con Facebook en la **aplicación del atacante**, el atacante podría obtener el **token OAuth del usuario otorgado a su aplicación y usarlo para iniciar sesión en la aplicación OAuth de la víctima usando el token de usuario de la víctima**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Por lo tanto, si el atacante logra que el usuario acceda a su propia aplicación OAuth, podrá tomar el control de la cuenta de la víctima en aplicaciones que esperan un token y no verifican si el token fue otorgado a su ID de aplicación.
|
||||
@ -164,7 +164,7 @@ Según [**este informe**](https://medium.com/@metnew/why-electron-apps-cant-stor
|
||||
|
||||
Para eludir este prompt, era posible abrir una pestaña para iniciar el **flujo de Oauth** que establecería esta cookie RU usando el **returnUrl**, cerrar la pestaña antes de que se muestre el prompt y abrir una nueva pestaña sin ese valor. Entonces, el **prompt no informará sobre el host del atacante**, pero la cookie se establecería en él, por lo que el **token se enviará al host del atacante** en la redirección.
|
||||
|
||||
### Bypass de interacción del prompt <a href="#bda5" id="bda5"></a>
|
||||
### Bypass de Interacción del Prompt <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Como se explica en [**este video**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), algunas implementaciones de OAuth permiten indicar el parámetro **`prompt`** GET como None (**`&prompt=none`**) para **evitar que se pida a los usuarios que confirmen** el acceso otorgado en un prompt en la web si ya están conectados a la plataforma.
|
||||
|
||||
@ -181,14 +181,14 @@ Como [**se explica en este video**](https://www.youtube.com/watch?v=n9x7_J_a_7Q)
|
||||
|
||||
Según [**esta publicación de blog**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), este es un flujo de OAuth que permite iniciar sesión en OAuth a través de **nombre de usuario** y **contraseña**. Si durante este flujo simple se devuelve un **token** con acceso a todas las acciones que el usuario puede realizar, entonces es posible eludir 2FA usando ese token.
|
||||
|
||||
### ATO en página web redirigiendo basado en redirección abierta al referer <a href="#bda5" id="bda5"></a>
|
||||
### ATO en página web redirigiendo basado en redirección abierta al referente <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Esta [**publicación de blog**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) comenta cómo fue posible abusar de un **redireccionamiento abierto** al valor del **referer** para abusar de OAuth para ATO. El ataque fue:
|
||||
Esta [**publicación de blog**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) comenta cómo fue posible abusar de un **redireccionamiento abierto** al valor del **referente** para abusar de OAuth para ATO. El ataque fue:
|
||||
|
||||
1. La víctima accede a la página web del atacante
|
||||
2. La víctima abre el enlace malicioso y un opener inicia el flujo de Google OAuth con `response_type=id_token,code&prompt=none` como parámetros adicionales usando como **referer el sitio web del atacante**.
|
||||
3. En el opener, después de que el proveedor autoriza a la víctima, los envía de vuelta al valor del parámetro `redirect_uri` (web de la víctima) con un código 30X que aún mantiene el sitio web del atacante en el referer.
|
||||
4. El **sitio web de la víctima activa el redireccionamiento abierto basado en el referer** redirigiendo al usuario víctima al sitio web del atacante, ya que el **`respose_type`** era **`id_token,code`**, el código se enviará de vuelta al atacante en el **fragmento** de la URL permitiéndole tomar el control de la cuenta del usuario a través de Google en el sitio de la víctima.
|
||||
2. La víctima abre el enlace malicioso y un opener inicia el flujo de Google OAuth con `response_type=id_token,code&prompt=none` como parámetros adicionales usando como **referente el sitio web del atacante**.
|
||||
3. En el opener, después de que el proveedor autoriza a la víctima, los envía de vuelta al valor del parámetro `redirect_uri` (web de la víctima) con un código 30X que aún mantiene el sitio web del atacante en el referente.
|
||||
4. El **sitio web de la víctima activa el redireccionamiento abierto basado en el referente** redirigiendo al usuario víctima al sitio web del atacante, ya que el **`respose_type`** era **`id_token,code`**, el código se enviará de vuelta al atacante en el **fragmento** de la URL permitiéndole tomar el control de la cuenta del usuario a través de Google en el sitio de la víctima.
|
||||
|
||||
### Parámetros SSRFs <a href="#bda5" id="bda5"></a>
|
||||
|
||||
@ -198,7 +198,7 @@ El Registro Dinámico de Clientes en OAuth sirve como un vector menos obvio pero
|
||||
|
||||
**Puntos Clave:**
|
||||
|
||||
- **El Registro Dinámico de Clientes** a menudo se mapea a `/register` y acepta detalles como `client_name`, `client_secret`, `redirect_uris`, y URLs para logotipos o Conjuntos de Claves Web JSON (JWKs) a través de solicitudes POST.
|
||||
- El **Registro Dinámico de Clientes** a menudo se mapea a `/register` y acepta detalles como `client_name`, `client_secret`, `redirect_uris`, y URLs para logotipos o Conjuntos de Claves Web JSON (JWKs) a través de solicitudes POST.
|
||||
- Esta característica se adhiere a las especificaciones establecidas en **RFC7591** y **OpenID Connect Registration 1.0**, que incluyen parámetros potencialmente vulnerables a SSRF.
|
||||
- El proceso de registro puede exponer inadvertidamente a los servidores a SSRF de varias maneras:
|
||||
- **`logo_uri`**: Una URL para el logotipo de la aplicación cliente que podría ser recuperada por el servidor, activando SSRF o llevando a XSS si la URL se maneja incorrectamente.
|
||||
@ -215,9 +215,31 @@ El Registro Dinámico de Clientes en OAuth sirve como un vector menos obvio pero
|
||||
|
||||
Si la plataforma que estás probando es un proveedor de OAuth [**lee esto para probar posibles Condiciones de Carrera**](race-condition.md).
|
||||
|
||||
## Ataque de Reclamaciones Mutables
|
||||
|
||||
En OAuth, el campo sub identifica de manera única a un usuario, pero su formato varía según el Servidor de Autorización. Para estandarizar la identificación del usuario, algunos clientes utilizan correos electrónicos o identificadores de usuario. Sin embargo, esto es arriesgado porque:
|
||||
|
||||
- Algunos Servidores de Autorización no garantizan que estas propiedades (como el correo electrónico) permanezcan inmutables.
|
||||
- En ciertas implementaciones—como **"Iniciar sesión con Microsoft"**—el cliente depende del campo de correo electrónico, que es **controlado por el usuario en Entra ID** y no verificado.
|
||||
- Un atacante puede explotar esto creando su propia organización de Azure AD (por ejemplo, doyensectestorg) y usándola para realizar un inicio de sesión en Microsoft.
|
||||
- Aunque el Object ID (almacenado en sub) es inmutable y seguro, la dependencia de un campo de correo electrónico mutable puede permitir un takeover de cuenta (por ejemplo, secuestrando una cuenta como victim@gmail.com).
|
||||
|
||||
## Ataque de Confusión de Cliente
|
||||
|
||||
En un **Ataque de Confusión de Cliente**, una aplicación que utiliza el Flujo Implícito de OAuth no verifica que el token de acceso final sea específicamente generado para su propio ID de Cliente. Un atacante configura un sitio web público que utiliza el Flujo Implícito de OAuth de Google, engañando a miles de usuarios para que inicien sesión y así recolectar tokens de acceso destinados al sitio del atacante. Si estos usuarios también tienen cuentas en otro sitio web vulnerable que no valida el ID de Cliente del token, el atacante puede reutilizar los tokens recolectados para hacerse pasar por las víctimas y tomar el control de sus cuentas.
|
||||
|
||||
## Ataque de Actualización de Alcance
|
||||
|
||||
El tipo de **Concesión de Código de Autorización** implica comunicación segura de servidor a servidor para transmitir datos de usuario. Sin embargo, si el **Servidor de Autorización** confía implícitamente en un parámetro de alcance en la Solicitud de Token de Acceso (un parámetro no definido en el RFC), una aplicación maliciosa podría actualizar los privilegios de un código de autorización solicitando un alcance más alto. Después de que se genera el **Token de Acceso**, el **Servidor de Recursos** debe verificarlo: para tokens JWT, esto implica verificar la firma JWT y extraer datos como client_id y scope, mientras que para tokens de cadena aleatoria, el servidor debe consultar al Servidor de Autorización para recuperar los detalles del token.
|
||||
|
||||
## Secuestro de Esquema de Redirección
|
||||
|
||||
En implementaciones móviles de OAuth, las aplicaciones utilizan **esquemas URI personalizados** para recibir redirecciones con Códigos de Autorización. Sin embargo, dado que múltiples aplicaciones pueden registrar el mismo esquema en un dispositivo, se viola la suposición de que solo el cliente legítimo controla la URI de redirección. En Android, por ejemplo, un URI de Intent como `com.example.app://` oauth se captura según el esquema y los filtros opcionales definidos en el intent-filter de una aplicación. Dado que la resolución de intent de Android puede ser amplia—especialmente si solo se especifica el esquema—un atacante puede registrar una aplicación maliciosa con un intent filter cuidadosamente elaborado para secuestrar el código de autorización. Esto puede **habilitar un takeover de cuenta** ya sea a través de la interacción del usuario (cuando múltiples aplicaciones son elegibles para manejar el intent) o mediante técnicas de bypass que explotan filtros excesivamente específicos, como se detalla en el diagrama de flujo de evaluación de Ostorlab.
|
||||
|
||||
## Referencias
|
||||
|
||||
- [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1)
|
||||
- [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors)
|
||||
- [**https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html**](https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -23,11 +23,11 @@ Los caracteres unicode generalmente se representan con el **prefijo `\u`**. Por
|
||||
Podrías usar esta técnica para **inyectar cualquier tipo de carácter** si el backend es vulnerable.\
|
||||
Consulta [https://unicode-explorer.com/](https://unicode-explorer.com/) para encontrar los caracteres que necesitas.
|
||||
|
||||
Esta vulnerabilidad proviene de una vulnerabilidad que un investigador encontró; para una explicación más detallada, consulta [https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg).
|
||||
Esta vulnerabilidad proviene de una vulnerabilidad que un investigador encontró, para una explicación más detallada consulta [https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg)
|
||||
|
||||
## Inyección de Emoji
|
||||
|
||||
Los back-ends a veces se comportan de manera extraña cuando **reciben emojis**. Eso es lo que sucedió en [**este informe**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) donde el investigador logró lograr un XSS con una carga útil como: `💋img src=x onerror=alert(document.domain)//💛`
|
||||
Los back-ends se comportan de manera extraña cuando **reciben emojis**. Eso es lo que sucedió en [**este informe**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) donde el investigador logró conseguir un XSS con una carga útil como: `💋img src=x onerror=alert(document.domain)//💛`
|
||||
|
||||
En este caso, el error fue que el servidor, después de eliminar los caracteres maliciosos, **convirtió la cadena UTF-8 de Windows-1252 a UTF-8** (básicamente, la codificación de entrada y la conversión de codificación no coincidían). Entonces, esto no da un < adecuado, solo uno unicode extraño: `‹`\
|
||||
``Así que tomaron esta salida y **convirtieron nuevamente ahora de UTF-8 a ASCII**. Esto **normalizó** el `‹` a `<`, así es como el exploit pudo funcionar en ese sistema.\
|
||||
@ -42,9 +42,23 @@ $str = iconv("UTF-8", "ASCII//TRANSLIT", $str);
|
||||
|
||||
echo "String: " . $str;
|
||||
```
|
||||
Listas de Emoji:
|
||||
Emoji lists:
|
||||
|
||||
- [https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv](https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv)
|
||||
- [https://unicode.org/emoji/charts-14.0/full-emoji-list.html](https://unicode.org/emoji/charts-14.0/full-emoji-list.html)
|
||||
|
||||
## Windows Mejor Ajuste/Pésimo Ajuste
|
||||
|
||||
Como se explica en **[esta gran publicación](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)**, Windows tiene una característica llamada **Mejor Ajuste** que **reemplazará caracteres unicode** que no se pueden mostrar en modo ASCII por uno similar. Esto puede llevar a un **comportamiento inesperado** cuando el backend está **esperando un carácter específico** pero recibe uno diferente.
|
||||
|
||||
Es posible encontrar caracteres de mejor ajuste en **[https://worst.fit/mapping/](https://worst.fit/mapping/)**.
|
||||
|
||||
Como Windows generalmente convertirá cadenas unicode a cadenas ascii como una de las últimas partes de la ejecución (generalmente pasando de una API con sufijo "W" a una API con sufijo "A" como `GetEnvironmentVariableA` y `GetEnvironmentVariableW`), esto permitiría a los atacantes eludir protecciones enviando caracteres unicode que se convertirán finalmente en caracteres ASCII que realizarían acciones inesperadas.
|
||||
|
||||
En la publicación del blog se proponen métodos para eludir vulnerabilidades corregidas utilizando una **lista negra de caracteres**, explotar **traversales de ruta** utilizando [caracteres mapeados a “/“ (0x2F)](https://worst.fit/mapping/#to%3A0x2f) y [caracteres mapeados a “\“ (0x5C)](https://worst.fit/mapping/#to%3A0x5c) o incluso eludir protecciones de escape de shell como `escapeshellarg` de PHP o `subprocess.run` de Python utilizando una lista; esto se hizo, por ejemplo, utilizando **comillas dobles de ancho completo (U+FF02)** en lugar de comillas dobles, de modo que al final lo que parecía ser 1 argumento se transformó en 2 argumentos.
|
||||
|
||||
**Nota que para que una aplicación sea vulnerable, necesita usar APIs de Windows "W" pero terminar llamando a una API de Windows "A", por lo que se crea el "Mejor ajuste" de la cadena unicode.**
|
||||
|
||||
**Varias vulnerabilidades descubiertas no se corregirán ya que las personas no están de acuerdo en quién debería solucionar este problema.**
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user