Re: Changing window.name behavior

+1 to what Artur said.

On Sat, Jul 9, 2016, 16:01 Artur Janc <aaj@google.com> wrote:

> On Thu, Jul 7, 2016 at 9:30 PM, Crispin Cowan <crispin@microsoft.com>
> wrote:
>
>> From an offline discussion, I do not believe that restrictions on length
>> and characters can be effective at stopping attacks while still permitting
>> window.name to be useful. For that reason, I think that our only options
>> are:
>>
>> 1.       Do nothing.
>>
>> 2.       Clear window.name upon navigation per the W3C spec.
>>
> These choices sound reasonable to me.
>
> Personally, I wouldn't terribly mind the second option since the
> window.name behavior is odd in the context of the SOP. That said,
> clearing it on cross-origin navigation will offer little security
> improvement because there are many ways to successfully exploit XSS even
> with a very short injection, e.g. by putting the payload in location.hash
> and calling "eval(location.hash.substr(1))" or
> "location=location.hash.substr(1)".
>
> I don't have a lot of data about real exploit payloads, but my guess is
> that the lack of window.name would not hinder attackers in any meaningful
> way.
>
>
>>
>>
>> This may break stuff. I look forward to the telemetry data to find out
>> how much stuff it would break.
>>
>>
>>
>> *From:* wilander@apple.com [mailto:wilander@apple.com]
>> *Sent:* Thursday, July 7, 2016 9:51 AM
>> *To:* public-webappsec@w3.org
>> *Subject:* Changing window.name behavior
>>
>>
>>
>> Hi Pub WebAppSec!
>>
>>
>>
>> *# About window.name <http://window.name>*
>>
>> The window.name property was publicly discussed at last week’s OWASP
>> AppSec in Rome. Three significant things appear to be true about this
>> property:
>>
>>    - It is a DOMString, meaning it can carry arbitrary Unicode.
>>    - There is no length restriction on it. Not by spec and not in
>>    implementations except for inherent restrictions on DOMStrings.
>>    - It does not get reset on cross-origin navigations.
>>
>>
>>
>> *# Security Implications*
>>
>> window.name can be used as an XSS payload carrier where attackers can
>> place large chunks of JavaScript and Unicode and then use it in an
>> injection. As an example:
>>
>>    1. Phish the victim to click a link <a href="evil.com">example.com</a>
>>    .
>>    2. On evil.com …
>>
>>
>>    1. Set window.name to javascript:[source code] for e.g. credential
>>       harvesting.
>>       2. Redirect to
>>       example.com/some/path/?xssVulnerability=location%3dname.
>>
>>
>>    1. example.com/some/path reflects location=name in a JavaScript
>>    context, executing the attack.
>>
>> Real life XSS vulnerabilities often impose size and character
>> restrictions on exploits which makes window.name handy for the attacker.
>> However, we don’t know how popular window.name is in XSS attacks. What
>> say the members of this list?
>>
>>
>>
>> *# Spec vs Reality*
>>
>> The HTML spec has at least the following to say about resetting
>> window.name:
>>
>>
>>
>> *5.2.2 APIs for creating and navigating browsing contexts by name*
>>
>> *…*
>>
>> *NOTE: The name gets reset when the browsing context is navigated to
>> another domain.*
>>
>>
>> https://www.w3.org/TR/html5/browsers.html#apis-for-creating-and-navigating-browsing-contexts-by-name
>>
>>
>>
>> … which links to:
>>
>>
>>
>> *5.6.10 History traversal*
>>
>> *…*
>>
>> *If the browsing context is a top-level browsing context, but not
>> an auxiliary browsing context, then the browsing context's browsing context
>> name must be unset.*
>>
>> https://www.w3.org/TR/html5/browsers.html#resetBCName
>>
>>
>>
>> This to me sounds like protection of sites you navigate to through
>> history, i.e. site C should not be able to set window.name for site A
>> and B when the user has visited A, B, C in that order and then navigates
>> history back and forth. Perhaps someone here can shed some light on what
>> this part of the spec implies? In any case, it's not what browsers do. Once
>> window.name is set it sticks. It sticks through regular forward
>> navigations (links etc) as well as history traversal back and forth.
>>
>>
>>
>> *# What Will Break If We Change It?*
>>
>> We don’t seem to have telemetry on window.name usage but Google has
>> kindly offered to capture some for us. MDN
>> <https://developer.mozilla.org/en-US/docs/Web/API/Window/name> mentions
>> target URLs for links and forms as well as cross-domain messaging in
>> frameworks such as Dojo. Any further insights from members of this list?
>>
>>
>>
>> *# Potential Changes*
>>
>> We could address all three things mentioned above, i.e. restrict
>> characters, restrict length, and reset on cross-origin navigations. But how
>> far do those changes have to go to do something meaningful about
>> window.name as an XSS payload carrier? And will window.name still be
>> useful for the benign cases under such restrictions, for instance sending
>> URLs?
>>
>>
>>
>>    Regards, John
>>
>