8

I have 3 domains : domainA domainB domainC

If I set target="_blank" on domainA with a link to domainC, domainC can access a bunch of property of domainA. That's why I use target="_blank" rel="noopener noreferrer". Otherwise, things like easier phishing are possible. Consider the following code on domainC :

if(window.opener){ window.opener.location="http://phishing.com" }

If domainA contains a link like <a href="https://domainC.com" target="_blank">, the condition will trigger and redirect domainA to attacker controlled domain. Otheres properties, like window.opener.length are readable.

While it is not really a vulnerability in fact because defined by the W3C, it is unknown from most developpers.

Now, I want to include an iframe from domainBin domainA, which I trust, but which is not protected against target="_blank" vulnerability.

I tested and clicked on a link on my iframe, and it looks like the window.opener wasn't null as it would be with noopener noreferrer, but I havn't be able to access attribute nor methods of it. When doing so (eg : redirecting), it prints :

Unsafe JavaScript attempt to initiate navigation for frame with URL domainB from frame with URL domainC. The frame attempting navigation is neither same-origin with the target, nor is it the target's parent or opener.

Then, can we consider it safe to include iframe without protection on target="_blank"?

Improve this question
10
  • Which window.opener properties are you concerned about? Commented Dec 5, 2016 at 16:01
  • What browser (and version) are you using? Commented Dec 5, 2016 at 16:18
  • 1
    I have been trying on Google Chrome and Firefox. I'm interested about all properties normally working with domainA to domainC, such as opener.location, window.opener.location, href. On Firefox, doing opener.location="mywebsite.com" result in [Exception... "<no message>" nsresult: "0x805e0006 (<unknown>)" location: "JS frame :: debugger eval code :: <TOP_LEVEL> :: line 1" data: no] and trying to get the location with alert(opener.location) result in error: Permission denied to access property Symbol.toPrimitive while it works with console.log(opener.location); Commented Dec 5, 2016 at 16:28
  • 1
    those properties are not really available between domains as you suggest. the console can see more properties than scripts can because scripts can't see the console output, so it's safe and helps devs debug cross-domain code. note that to an opener, "location.href" is write-only (console aside), which is unusual and potentially confusing. Can you elaborate on a target="_blank" vulnerability.? i've not heard of such a concept, so it's hard for us to give you an answer. Commented Dec 8, 2016 at 21:44
  • 1
    I'm having the exact same issue, but without the iframe. I'm simply trying to redirect the opener. I get Error: Permission denied to access property Symbol.toPrimitive though. Can you please explain to me what that is? Edit: If you need to view the headers or something, feel free to check them at arinerron.com Commented Dec 17, 2016 at 21:58

1 Answer 1

Reset to default
2
+25

You are looking for the "sandbox" attribute : https://developer.mozilla.org/en/docs/Web/HTML/Element/iframe

allow-top-navigation: Allows the embedded browsing context to navigate (load) content to the top-level browsing context. If this keyword is not used, this operation is not allowed.

Improve this answer
3
  • 2
    Well, it doesn't allow to access parent element, but which of the iframes properties can we access ? Commented Dec 6, 2016 at 19:08
  • 1
    i don't think "framebusting" is the concern raised by OP... Commented Dec 8, 2016 at 21:45
  • @dandavis it's one of the concern: it's about .location being writable. But my answer doesn't covert the other details. I wish somebody could improve it. Commented Dec 9, 2016 at 10:17

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.