- From: RelunSec <notifications@github.com>
- Date: Mon, 05 Jan 2026 03:50:37 -0800
- To: whatwg/url <url@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/url/issues/893/3710112963@github.com>
HackingRepo left a comment (whatwg/url#893) Thanks everyone for the thoughtful replies. My intent here wasn’t to re‑open closed topics, but to highlight that certain malformed URL patterns (like repeated slashes or unusual encodings) often show up in real attack attempts. I agree with Anne that arbitrary limits can be tricky to standardize, but I also see moisrex’s point that implementers may benefit from clearer guidance or warnings when these patterns occur. I’ll avoid the term bypass since it may be misleading -- what I meant was that mismatches between parsed and raw URLs can create TOCTOU‑like risks if not handled consistently. I appreciate the feedback on style too; I’m not trying to flood the discussion, just to make sure the security angle is visible. Happy to step back if this feels repetitive, and I’ll focus on concrete examples or vendor behaviors where possible. And importantly that problem bypass WAFS and Rules so like CoreRuleSet the issue in https://github.com/coreruleset/coreruleset/issues/4384 that normalization cause the issue, i say an important sentence in cybersecurity "Never try to fix user input, Instead suggest the fix to the user to explicitly fix it" why that? because the normalizer help the attacker to bypass WAF by example https:google.com to https://google.com the waf see only https:google.com not https://google.com and evade detection that need to be fixed that is very serioius security issue. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/url/issues/893#issuecomment-3710112963 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/url/issues/893/3710112963@github.com>
Received on Monday, 5 January 2026 11:50:41 UTC