7

Basically, I am having an <a> tag with target set to _blank, where an attacker has control over the href parameter, thus possible inserting a javascript tag, like the following:

<a target="_blank" href="javascript:alert(document.location)">

However, this XSS executes in a new about:blank tab because of the target setting.

Is it possible to bypass this, and let the javascript execute on the original page with the control of the href parameter?

3
  • 1
    Why cant they just close the <a> tag and begin a new tag?
    – yeah_well
    Aug 28, 2019 at 19:21
  • is the opener property available to the popup code?
    – dandavis
    Aug 28, 2019 at 19:28
  • 1
    What characters (if any) are escaped? Are we assuming proper attribute escaping?
    – Gray
    Aug 28, 2019 at 20:29

3 Answers 3

4

You can use window.opener to exploit this (fiddle):

<a target="_blank" href="javascript:alert(window.opener.document.cookie);">test</a>

Or if you can escape the attribute value context, you can start a new script tag or a new attribute like onMouseEnter.

2
  • 1
    I can't reproduce this (anymore), JS doesn't seem to execute if the link targets a _blank window. Mind having a look?
    – Arminius
    Feb 1, 2021 at 20:25
  • It doesn't work on mine as well. It is blocked on my Chrome Browser. Jun 11, 2023 at 15:18
1

Use a data: URI. Data URIs let you encode arbitrary content (including HTML and JS), with a content type of your choice, into a URL. They don't (inherently) cause a network request; the browser just loads the content directly. In the scenario you have here, you would then be able to use the window.opener property (within the new page) to drive the vulnerable site. Windows (including iframes, and probably new tabs) that load Data URIs don't create a new origin - they inherit the origin of the page that they are loaded from - so you should have full access to the opener's DOM and be able to make same-origin XHR/Fetch requests (with authentication/cookies and access to responses) to the domain.

Of course, all this assumes you cannot just break out of the "href" attribute to add a new attribute (such as an event handler, which would fire on the existing tab not the new location), or out of the anchor element entirely and add your own element (such as a script tag).

3
  • What about this security.stackexchange.com/questions/214450/…
    – tungsten
    Aug 28, 2019 at 23:33
  • @tungsten It sounds like the obfuscation in that answer isn't needed, but yes, that's the general idea.
    – CBHacking
    Aug 29, 2019 at 1:01
  • I tried this: data:text/html,<script>alert('XSS')</script>, but it requires me to refresh the page or manually load the URL to see the effect Jun 11, 2023 at 15:42
1

This bug has been solved with new HTML tag rel=”noreferrer noopener”

it means no referrer information should be passed to the website being linked (noreferrer) to and noopener prevents the newly opened page from having the ability to control the page that delivered the traffic

<a target="_blank" rel="noopener noreferrer" href="javascript:alert(document.location)">Safe</a>

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .