Authorization header leak in ssrf_filter via cross-host redirect leads to credential theft and unauthorized access

## Summary: `ssrf_filter` follows redirects by rebuilding each redirected request from the original request options. When a redirect crosses to a different host, it still reapplies caller-supplied sensitive state such as the `Authorization` header. As a result, an attacker-controlled redirect target can receive credentials that were intended only for the original request origin. I verified impact with a local proof of concept. A bearer token attached to the initial request was forwarded to a different host, captured there, and then successfully replayed against a separate protected API endpoint, which returned private data. This demonstrates credential theft followed by unauthorized access, not just passive header disclosure. ## Steps To Reproduce: 1. Clone the repository and enter the project root: ```bash git clone https://github.com/arkadiyt/ssrf_filter cd ssrf_filter ``` 2. Run the attached bearer-token replay PoC: ```bash ruby artifacts/ssrf_filter_redirect_leak_2026-04-01/01_bearer_token_replay.rb ``` 3. The PoC starts three local servers: - redirector.test, which returns a 302 redirect to collector.test - collector.test, which records the inbound Authorization header - api.test, which exposes /private and only returns data when the correct bearer token is presented 4. Observe that SsrfFilter.get(...) follows the redirect and forwards the original Authorization header to collector.test. 5. Observe that the stolen token is then replayed to api.test/private and succeeds. Expected output: ``` [:fetch_response, "200", "stolen"] [:stolen_token, "Bearer service-token-123"] [:replay_response, "200", "private-data"] ``` Interpretation: - Authorization is forwarded across an origin change. - The leaked bearer token is reusable. - Reuse of the stolen token grants access to protected data. Note: for local-only reproduction, the PoC temporarily allows loopback addresses so the entire harness can run on one machine. That adjustment is only for the lab setup and is not part of the vulnerability itself. The issue is the forwarding of sensitive credentials across cross-host redirects. ## Supporting Material/References: * Evidence bundle: ssrf_filter/artifacts/ssrf_filter_redirect_leak_2026-04-01.zip * Bearer token replay PoC: ssrf_filter/artifacts/ssrf_filter_redirect_leak_2026-04-01/01_bearer_token_replay.rb * Evidence outputs: ssrf_filter/artifacts/ssrf_filter_redirect_leak_2026-04-01/evidence_outputs.md * Draft report: ssrf_filter/artifacts/ssrf_filter_redirect_leak_2026-04-01/report_draft.md * Relevant code path: ssrf_filter/lib/ssrf_filter/ssrf_filter.rb - redirect loop reuses the original request options - redirected requests reapply headers/body/request_proc - redirects are not differentiated between same-host and cross-host targets