Could you please provide a more detailed attack scenario?

Because file:// URLs are loading their own unique origins, a webpage that loads a file:// URL inside an iframe should be not be able to access the local filesystem in any way.

This vulnerability could result in the exposure of sensitive data or could potentially lead to the corruption of system critical files.
However i am able to access the local file system from the iframe as well which will leads to iFrame Zone Restricted bypass.

Works for me in Linux as well.
Version : Chrome-beta

Deleted: POC.png 58.5 KB

	POC.png 58.5 KB View Download

dcheng, mkwst, do you have any thoughts about file:// URLs loading other file:// URLs in iframes? I don't know if it's that much different than being allowed to load other file:// URLs in images, except perhaps that one file:// URL could clickjack another.

I agree with estark@ that the normal cross-origin properties of the frame should be a reasonable defense against exfiltration. mishra.dhiraj95@: do you have specific attack scenarios in mind when you're talking about "iFrame Zone Restricted bypass"?

That said, I'm surprised that we allow websites to load `file:` in an iframe. I thought we blocked that. Looking at the code, https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/weborigin/SecurityOrigin.cpp?rcl=1485491011&l=336 seems to agree with me. I'm on a Chromebook at the moment, so I don't actually _have_ a filesystem with which to replicate the error... Emily, would you mind giving it a try?

Yeah, we don't allow "real" websites to load file:// URLs in frames. AFAIU this report is just about file:// URL being able to load other file:// URLs in frames, so one file:// URL could, for example, clickjack another file:// URL.

Ah. I see. `file:` can frame `file:` today, you're right. But that's a fairly different threat model than the web being able to frame `file:`. :)

I guess I'm still curious about what this enables that we'd want to prevent. +lgarron@, who cares about `file:` more than I do.

If file:// pages couldn't embed things from file:// origins, this would break save page.

I suppose it could allow potential clickjacking attacks against files at a fixed location (poorly written management console for some local app?), but the risk doesn't seem that high. As file:// origins themselves are unique, the standard cross-origin protections still apply. Unless there's something new to consider here, I think this is WAI.

I agree the risk is low and not worth breaking useful functionality.

OP, please feel to free to post more detail if you think there's something we've missed. Thanks!

I dont have any specific attack scenario for now, there are various different models of attack that can be performed for this moment.

Request you to please have a look again because for now you may be right but a fix may be needed in future.

And this works perfect for me in 

Mozilla : Bug id=1335301
and Edge and IE as well.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot