When you parse a URL for allowlisting like this, you need to recompose it from the parsed pieces, rather than allowing it past in its original form. This helps avoid the “dueling parsers” class of vulnerabilities.
It’s very telling/disappointing that Google’s fix was to change their library to use the broken definition of URL that WHATWG promulgates, rather than following RFC 3986 like everyone else. (What is WHATWG smoking, anyhow?)
WHATWG documented what’s actually implemented in browsers rather than the platonic ideal as originally designed.
That has the same feel of an electrical standards body standardizing shoving pennies in fuse boxes because everyone’s already doing it.
It’s more like how dictionaries describe language as it is used rather than proscribing how language should be used.
Dictionary publishers don’t claim to be standards bodies. If WHATWG just wanted to describe, not prescribe, I’d be fine with their inclusion of backslash. But they can’t have it both ways, at least not without big caveats in the description/standard.
Who cares about what browsers implement, none of this even happens clientside?
It turns out that sometimes servers talk to clients and it’s useful for servers to be able to reason about how clients will interpret various data formats. That was, it turns out, a bad choice of library for this particular case.
Getting three bounties from one bug by checking whether it was really fixed or not was a neat trick.
That kind of whack-a-mole interaction is usually the kind of thing I would expect from a more green security response team, not… Google.
Google has so many teams in it that even if the average is pretty good, there are going to be a few teams that are much worse than the average. Perhaps the author just happened to get lucky by finding one.
(And perhaps Google’s average standard is worse than they like to think it is.)