1369029 - Consider blocking requests to HTTP(S) URLs that contain both `\n` and `<` characters.

Status: NEW

(Core :: Networking, enhancement, P3)

Description

[Mike West]

In the hopes of mitigating one form of dangling-markup-based exfiltration, Blink plans to block requests whose URLs contained both removable whitespace (`\n`, `\r`, `\t`) _and_ raw less-than (`<`) characters. https://github.com/whatwg/fetch/issues/546 lays out the strategy and justification in more detail, proposed patches to URL and Fetch are up for review at https://github.com/whatwg/url/pull/284 and https://github.com/whatwg/fetch/pull/519 respectively, and Blink's "Intent to Remove" might be helpful: https://groups.google.com/a/chromium.org/d/msg/blink-dev/KaA_YNOlTPk/VmmoV88xBgAJ.

WDYT?

Comment 1

[Valentin Gosu [:valentin] (he/him)]

This seems like a very good idea, with clear security benefits.
I'll get started on a patch in a couple of weeks.

Comment 2

[Firefox Bug Husbandry Bot]

Bulk priority update: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 3

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 4

[Valentin Gosu [:valentin] (he/him)]

Not on my priority list right now.

Comment 5

[Frederik Braun [:freddy]]

This "might" be doable, summarizing what Valentin suggested in chat:

It should be possible to do that when parsing a URL. So in NS_NewURI / nsStandardURL::SetSpecWithEncoding. We could save the flag on the URL, object when parsing, then check it in nsHttpChannel::AsyncOpen and fail the channel if it's set