21975 2008-10-30 10:15:08 -0700 decodeURLEscapeSequences will generate embedded null characters 2024-04-29 05:37:56 -0700 1 1 1 Unclassified WebKit Platform 528+ (Nightly build) All All NEW P2 Normal --- 37641 1 brettw webkit-unassigned abarth ahmad.saleem792 annevk ap oldest_to_newest 97134 0 brettw 2008-10-30 10:15:08 -0700 This function will convert %00 to an embedded null character in the output string. This function is used in many of KURL's getters. This is potentially dangerous. IE, Firefox, and Google Chrome don't convert %00 to NULL, even in Javascript URLs. Some APIs don't expect embedded NULLs. One such API is KURL::init. It does things like this: while (*relStringPos && *relStringPos != '?' && *relStringPos != '#') { which will stop at an embedded NULL. This means that if you build up a URL from parts extracted from a different URL, it could be completely different. This could be a security bug. 2029865 1 ahmad.saleem792 2024-04-19 09:06:53 -0700 @Anne - you worked in URL space heavily in past year or so, is this bug applicable anymore? 2031846 2 annevk 2024-04-29 05:37:56 -0700 I'm not sure, but there is behavior here that is not defined in the specification. Compare: data:text/html,a%00a data:text/html,a%01a In the first data: URL the 0x00 byte is dropped. The 0x01 byte is preserved. That does not seem like great behavior to me. I filed https://github.com/whatwg/fetch/issues/1748 as a start. Now obviously we have to look at other consumers as well for this bug to fully rule out anything problematic.