Re: Changing window.name behavior

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
>