Re: Changing window.name behavior

It is, as you say, handy for the attacker.  But, I don't know how popular
malicious use is in the wild.

It's been discussed for a long time though - I learned about it here,
http://www.thespanner.co.uk/2007/09/06/window-name-trick/

Maybe open a bug report for the browsers that are not following the specs?

I think there was one for Mozilla once.

Dan

On Thu, Jul 7, 2016 at 11:50 AM John Wilander <wilander@apple.com> wrote:

> 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.
>    3. 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
>