Restrict `<base target>` from including newlines.

[mikewest]

As noted in http://www.w2spconf.com/2012/papers/w2sp12-final11.pdf and discussed a bit in https://github.com/w3c/webappsec-csp/issues/186, an unclosed target attribute of <base> can inadvertently suck up large chunks of the remainder of the page, using them as the window.name of any navigations triggered by the page.

https://www.chromestatus.com/metrics/feature/timeline/popularity/1761 shows that, for Chrome users, the target attribute contains a \n character approximately 0% of the time. Perhaps it would be reasonable to simply restrict such values from being used as a target. For example, we could do something like changing step 5 of https://html.spec.whatwg.org/#following-hyperlinks-2 to use the target attribute iff it doesn't contain a \n character.

WDYT, @mozfreddyb, @johnwilander, @travisleithead, etc?

[annevk]

That would not cover <form>. Patching "the rules for choosing a browsing context" where the value is actually used seems slightly better, though would affect window.open() as well.

[mikewest]

I see.

I didn't look at "the rules for choosing a browsing context" because I'm not sure whether affecting window.open() is reasonable. I vaguely recall weird ad networks using the window name to transfer data across the window boundary. Not sure if that's done a priori via targeting, or after the fact by setting window.name.

[annevk]

Okay, it seems like we should make sure it affects both <form> and <a>/<area> though. There's some opportunity there to deduplicate a bit of target handling so that would probably work out well.

[mikewest]

Ok. If none of the fine folks CC'd here object fundamentally, I'll try to put together a patch and some tests.