New weakness: untrusted HTML targets. HTML target= and window.open() enables easy reverse tabnabbing

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

New weakness: untrusted HTML targets. HTML target= and window.open() enables easy reverse tabnabbing

Wheeler, David A

A widespread weakness appears to be missing from the CWEs.  Here’s a summary with references.

 

The weakness is the use of untrusted HTML targets, typically via unmitigated uses of HTML “<a … target=>” or JavaScript window.open().  These are widely used to create displays in a “new place” (like a new tab).  E.g., in HTML, <a href="https://malware.com" target="_blank">click</a> when clicked creates a new tab with the content from the specific href.  The *default* target for window.open() is “_blank” which creates a new tab (and is a dangerous default).

 

Unfortunately, using values of target other than “_self” creates a potential vulnerability.  In such cases, the page being linked to runs in the same process as calling page, and this enables JavaScript in the *called* page to have some control over the *calling* page, *even* if they’re not in the same origin.  The control is somewhat limited, but those limitations aren’t enough to prevent attacks.  For example, without mitigations, the called tab can trivially run JavaScript such as window.opener.location = newURL; this will force the *calling* tab to be reloaded with the the content of an arbitrary new location of the attacker’s choosing.

 

This enables a *really* easy reverse tabnabbing that’s very hard to detect. With this vulnerability, the attacker can force the calling tab to be loaded to be a malware site that *looks* identical to the original correct site, within the very same tab that originally *was* the correct site.  Very few users would notice this kind of switch.

 

The best solution is to eliminate the use of target=… and window.open() for target values other than “_self” (such as the vulnerable “_blank”), particularly if the called tab includes user-provided data or is in any way untrustworthy.  There may be other target values that are safe, I haven’t delved into that.

 

Failing that, there are some decent imperfect mitigations.  In HTML a good mitigation is to include rel="noopener" after target=”…”.  In JavaScript, after all call to window.open like “var newWnd = window.open()”, do “newWnd.opener = null;” and then load the new page contents; that way the called tab won’t be able to easily access the window opener using “.opener”.  This doesn’t completely eliminate the attack; they’re still in the same process, and there are other ways an attacker might succeed in getting access to the calling window (e.g., using “window.open” if the attacker can determine the window name of the tab to be subverted).  The rel="noopener" mitigation is supported by at least Chrome 49+, Firefox 52+, Opera 36+, and Safari since late 2016.

 

I personally think this is a clear violation of the “same-origin” policy that web browsers are supposed to follow, but nobody asked me :-).  I think it is *crazy* that these defaults are dangerous; this should be prohibited by default, and enabled only via CSP.  But I digress.

 

A summary of this type of vulnerability is here: “Target="_blank" - the most underestimated vulnerability ever” by Alexander "Alex" Yumashev, 2016-05-04, https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/

 

More information here:

  Lighthouse, “Opens External Anchors Using rel="noopener“, 2017, https://developers.google.com/web/tools/lighthouse/audits/noopener

  https://mathiasbynens.github.io/rel-noopener/

  https://jakearchibald.com/2016/performance-benefits-of-rel-noopener/

  https://developers.google.com/web/tools/lighthouse/audits/noopener

  https://sites.google.com/site/bughunteruniversity/nonvuln/phishing-with-window-opener

  https://news.ycombinator.com/item?id=15685324

  https://addons.mozilla.org/en-US/firefox/addon/dont-touch-my-tabs/?src=cb-dl-created

  Note that “noopener” was added to Firefox in version 52: https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types

  Added to Safari late 2016: https://webkit.org/blog/7071/release-notes-for-safari-technology-preview-17/

  Some discussion here: https://developer.mozilla.org/en-US/docs/Web/API/Window/open#Note_on_use_of_window_open

 

--- David A. Wheeler

 

 

 

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: New weakness: untrusted HTML targets. HTML target= and window.open() enables easy reverse tabnabbing

Andrew Buttner
Administrator
This is actually an issue that was proposed to us last month and will be part of the CWE 3.0 release that will happen this week. The new CWE is:

======================

CWE-1022:

Title = Improper Restriction of Cross-Origin Permission to window.opener.location

Description = The web application does not restrict or incorrectly restricts modification of its window opener object's location property by an external application from a different origin.

Extended Description = By default, many browsers that open a link to an external application with a target specified as a new window/tab provide cross-origin access to the location property via a window.opener object. This enables the external application to choose a location to redirect the calling web application, e.g. for a phishing attack.

=======================

Once this is released, if there are modification / updates that should be made, then we can work to do so. There is a lot of potential additional information in David's email that we could add to the new CWE.

Thanks
Drew


> -----Original Message-----
> From: [hidden email] [mailto:owner-cwe-research-
> [hidden email]] On Behalf Of Wheeler, David A
> Sent: Tuesday, November 14, 2017 6:48 PM
> To: cwe-research-list CWE Research Discussion <cwe-research-
> [hidden email]>
> Cc: Black, Paul E. (Fed) <[hidden email]>
> Subject: New weakness: untrusted HTML targets. HTML target= and
> window.open() enables easy reverse tabnabbing
>
> A widespread weakness appears to be missing from the CWEs.  Here's a
> summary with references.
>
>
>
> The weakness is the use of untrusted HTML targets, typically via unmitigated
> uses of HTML "<a ... target=>" or JavaScript window.open().  These are
> widely used to create displays in a "new place" (like a new tab).  E.g., in
> HTML, <a href="https://malware.com" target="_blank">click</a> when
> clicked creates a new tab with the content from the specific href.  The
> *default* target for window.open() is "_blank" which creates a new tab (and
> is a dangerous default).
>
>
>
> Unfortunately, using values of target other than "_self" creates a potential
> vulnerability.  In such cases, the page being linked to runs in the same
> process as calling page, and this enables JavaScript in the *called* page to
> have some control over the *calling* page, *even* if they're not in the same
> origin.  The control is somewhat limited, but those limitations aren't enough
> to prevent attacks.  For example, without mitigations, the called tab can
> trivially run JavaScript such as window.opener.location = newURL; this will
> force the *calling* tab to be reloaded with the the content of an arbitrary
> new location of the attacker's choosing.
>
>
>
> This enables a *really* easy reverse tabnabbing that's very hard to detect.
> With this vulnerability, the attacker can force the calling tab to be loaded to
> be a malware site that *looks* identical to the original correct site, within the
> very same tab that originally *was* the correct site.  Very few users would
> notice this kind of switch.
>
>
>
> The best solution is to eliminate the use of target=... and window.open() for
> target values other than "_self" (such as the vulnerable "_blank"),
> particularly if the called tab includes user-provided data or is in any way
> untrustworthy.  There may be other target values that are safe, I haven't
> delved into that.
>
>
>
> Failing that, there are some decent imperfect mitigations.  In HTML a good
> mitigation is to include rel="noopener" after target="...".  In JavaScript, after
> all call to window.open like "var newWnd = window.open()", do
> "newWnd.opener = null;" and then load the new page contents; that way
> the called tab won't be able to easily access the window opener using
> ".opener".  This doesn't completely eliminate the attack; they're still in the
> same process, and there are other ways an attacker might succeed in getting
> access to the calling window (e.g., using "window.open" if the attacker can
> determine the window name of the tab to be subverted).  The
> rel="noopener" mitigation is supported by at least Chrome 49+, Firefox 52+,
> Opera 36+, and Safari since late 2016.
>
>
>
> I personally think this is a clear violation of the "same-origin" policy that web
> browsers are supposed to follow, but nobody asked me :-).  I think it is
> *crazy* that these defaults are dangerous; this should be prohibited by
> default, and enabled only via CSP.  But I digress.
>
>
>
> A summary of this type of vulnerability is here: "Target="_blank" - the most
> underestimated vulnerability ever" by Alexander "Alex" Yumashev, 2016-05-
> 04, https://www.jitbit.com/alexblog/256-targetblank---the-most-
> underestimated-vulnerability-ever/ <https://www.jitbit.com/alexblog/256-
> targetblank---the-most-underestimated-vulnerability-ever/>
>
>
>
> More information here:
>
>   Lighthouse, "Opens External Anchors Using rel="noopener", 2017,
> https://developers.google.com/web/tools/lighthouse/audits/noopener
>
>   https://mathiasbynens.github.io/rel-noopener/
>
>   https://jakearchibald.com/2016/performance-benefits-of-rel-noopener/
>
>   https://developers.google.com/web/tools/lighthouse/audits/noopener
>
>   https://sites.google.com/site/bughunteruniversity/nonvuln/phishing-with-
> window-opener
>
>   https://news.ycombinator.com/item?id=15685324
>
>   https://addons.mozilla.org/en-US/firefox/addon/dont-touch-my-
> tabs/?src=cb-dl-created
>
>   Note that "noopener" was added to Firefox in version 52:
> https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types
>
>   Added to Safari late 2016: https://webkit.org/blog/7071/release-notes-for-
> safari-technology-preview-17/
>
>   Some discussion here: https://developer.mozilla.org/en-
> US/docs/Web/API/Window/open#Note_on_use_of_window_open
>
>
>
> --- David A. Wheeler
>
>
>
>
>
>
>
>
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have
> difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].