- From: RelunSec <notifications@github.com>
- Date: Sat, 03 Jan 2026 23:48:49 -0800
- To: whatwg/url <url@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/url/issues/893/3707835091@github.com>
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