W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2016

Re: Changing window.name behavior

From: Dan Anderson <dan-anderson@cox.net>
Date: Thu, 07 Jul 2016 19:11:06 +0000
Message-ID: <CAN5uf-TZ8SUQkbTNL8y7vnem2nX2L1gs_a+7E_34wm2C34R5UA@mail.gmail.com>
To: John Wilander <wilander@apple.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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,

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

I think there was one for Mozilla once.


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
Received on Tuesday, 12 July 2016 14:33:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:56 UTC