RE: Changing window.name behavior

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.

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
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<http://evil.com>">example.com<http://example.com></a>.
  2.  On evil.com<http://evil.com> …

     *   Set window.name to javascript:[source code] for e.g. credential harvesting.
     *   Redirect to example.com/some/path/?xssVulnerability=location%3dname<http://example.com/some/path/?xssVulnerability=location%3dname>.

  1.  example.com/some/path<http://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