# HostAuthorization middleware does not suitably sanitize the Host / X-Forwarded-For header allowing redirection.

Rails HostAuthorization's leading-dot host regex is too permissive, so a crafted Host header like google.com#sub.tkte.ch passes validation and redirects users off-site.

- Payout: hidden
- Severity: low
- Program: Ruby on Rails
- Found by: tktech
- Disclosed: 2021-02-11
- CVE: CVE-2021-22881
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/1047447
- Library page: https://bugbountylibrary.com/r/h1%3A1047447
- Tags: area:web domain:web impact:integrity kind:bounty platform:hackerone sev:low tech:ruby technique:source-review vuln:host-header vuln:open-redirect

**Target:** HostAuthorization middleware / Host header validation
**Root cause:** sanitize_string wraps leading-dot hosts in /\A(.+\.)?<host>\z/ which matches any prefix ending in the domain, so 'google.com#sub.tkte.ch' passes and is used verbatim in redirect Location.
**Steps:**
1. Configure config.hosts << '.tkte.ch'
2. Send `curl -i -H "Host: google.com#sub.tkte.ch" http://localhost:3001/`
3. Middleware accepts host; controller redirect_to emits Location: http://google.com#sub.tkte.ch/
**How found:** A third-party reported host header poisoning; tracing it led to the sanitize_string regex being too permissive for leading-dot host configs.
**Exploitation:** Attacker supplies a crafted Host header whose value ends with the allowed domain but begins with an arbitrary external host plus '#', causing the app's relative redirect to resolve to the attacker-controlled origin.
**Insight:** When a framework converts a config string into an anchored regex, test whether the prefix group (.+\.)? can be satisfied by attacker-controlled host syntax like '#', '@', or userinfo delimiters that browsers treat as origin boundaries.