9

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"?

Xavier59
  • 2,874
  • 3
  • 17
  • 34
  • Which `window.opener` properties are you concerned about? – SilverlightFox Dec 05 '16 at 16:01
  • What browser (and version) are you using? – Anders Dec 05 '16 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... "" nsresult: "0x805e0006 ()" location: "JS frame :: debugger eval code :: :: 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);` – Xavier59 Dec 05 '16 at 16:28
  • So, it is a bit blurred to understand what is under the SOP and what is not. – Xavier59 Dec 05 '16 at 16:30
  • When you open the iframe containing `B` on a page from `A`, is `A` the top level frame? If not, I think that might be it. – Anders Dec 05 '16 at 16:33
  • 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. – dandavis Dec 08 '16 at 21:44
  • @dandavis I have updated my post, but you can find a lot of documentation about it on internet. – Xavier59 Dec 09 '16 at 00:54
  • This is currently exploitable on Facebook -> https://psyadmin.com/2016/12/03/facebook-tabnabbing-proof-of-concept/ – Jay Dec 09 '16 at 13:46
  • there is no security issue, known vulnerability, or exploit surrounding the lack of use of newer link _rel_ attribs; the SOP already protects such interaction. the `noreferrer` rel is more about privacy, while `noopener` is about poor UX stemming from over-zealous framebusting and tracking attempts redirecting the first tab. Note that the _entire_ risk is that they can _navigate_ that first tab; they cannot read any info from it or otherwise affect it, so it's perhaps an annoyance, but not a security issue. put this one to bed, nothing to see, ask FB... – dandavis Dec 09 '16 at 20:51
  • 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 https://arinerron.com – Aaron Esau Dec 17 '16 at 21:58

1 Answers1

1

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.

Tom
  • 2,063
  • 12
  • 19
  • 2
    Well, it doesn't allow to access parent element, but which of the iframes properties can we access ? – Xavier59 Dec 06 '16 at 19:08
  • 1
    i don't think "framebusting" is the concern raised by OP... – dandavis Dec 08 '16 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. – Tom Dec 09 '16 at 10:17