Re: [whatwg/url] Malformed URL Normalization in Standard Introduces SSRF Risks (Issue #893)

HackingRepo left a comment (whatwg/url#893)

Thanks for the feedback. Let me clarify the attack vector more concretely:

The issue arises when a filter rejects a malformed input string, but the parser later normalizes it into a valid URL. That creates a mismatch between “invalid at filter stage” and “valid at parser stage,” which attackers can exploit.

For example:
- Input: `http:127.0.0.1/`
- Filter: rejects as malformed (no `//` after scheme)
- Parser: normalizes into `http://127.0.0.1/`
- Result: request succeeds, bypassing the filter

This matters because in practice:
- **Filters often operate on raw input** (e.g. WAF rules, SSRF guards).
- **Parsers normalize aggressively** for interoperability.
- If the filter and parser disagree, the attacker wins.

I agree that ideally the entire system should use the same parser. But in reality:
- Ecosystems mix parsers (Node’s `url`, Rust’s `url`, Python’s `urllib`, curl, etc.).
- Some parsers are spec‑compliant, others are “garbage‑in‑garbage‑out.”
- Normalization rules differ, so a filter written against one parser may be bypassed when another parser is used downstream.

That’s why I think the spec should explicitly call out **special schemes** (`http`, `https`, `ftp`, `file`) and warn that normalization of malformed inputs in these schemes can introduce SSRF/WAF bypasses. Even if the spec doesn’t change parsing rules, a **security note** would help implementers understand that conversion ≠ validation, and that filters must reject malformed inputs before parsing.

So the proposal isn’t to make the parser itself a validator, but to document the risk and encourage libraries to expose a strict mode or validation API for security‑sensitive contexts.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/893#issuecomment-3707835091
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/issues/893/3707835091@github.com>

Received on Sunday, 4 January 2026 07:48:53 UTC