Bug 21975
| Summary: | decodeURLEscapeSequences will generate embedded null characters | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Brett Wilson (Google) <brettw> |
| Component: | Platform | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | abarth, ahmad.saleem792, annevk, ap |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | |||
| Bug Blocks: | 37641 | ||
Brett Wilson (Google)
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Ahmad Saleem
@Anne - you worked in URL space heavily in past year or so, is this bug applicable anymore?
Anne van Kesteren
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.