Sorry, this is my first time filing a Chrome bug. This isn't actually a security issue, it should be in Blink>SecurityFeature>ContentSecurityPolicy

Thanks for the bug!

No problem, thanks for cleaning up the filing, Eric ! 

ian.melven@ - Thanks for filing the issue...!!

Could you please provide consistent reproducible steps to test the issue from TE-end. Also if possible please provide a screen shot or screen cast explaining the exact issue. Please provide sample credentials to login to the page at URL: http://rpm.newrelic.com/.
This will help us in triaging the issue further.

Thanks...!!

krajshree@ Thanks for taking a look at the bug ! 

Here is our developer's repro case and notes : 

It requires Ruby but no dependencies outside the standard library. Please see local_content.rb and haha-iframes.html, attached. To test, first run ruby local_content.rb at the terminal and then visit file:///wherever/you/saved/haha-iframes.html in both Chrome and Safari.

Safari will render the inner content inside the iframe. 

Chrome will leave the iframe blank and will display the following message in the developer console:
Refused to display 'http://localhost:8000/inner' in a frame because an ancestor violates the following Content Security Policy directive: "frame-ancestors : file: *.newrelic.com"." 

Deleted: haha-iframes.html 184 bytes

haha-iframes.html 184 bytes View Download

Deleted: local_content.rb 304 bytes

local_content.rb 304 bytes View Download

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

As per Comment#2 considering the above issue as feature and marking it as Untriaged.

This isn't a feature request, it's a claim of a bug in the frame-ancestors matching logic.

Here's a simpler repro page: https://bayden.com/test/csp/frame-ancestors.aspx

I cannot reproduce the problem described using Chrome 63.3207 or Chrome 60.3112 on Windows.

(The ruby script in comment #5 has an extra colon in the Content-Security-Policy header, but this seems to be ignored).

Oh, interesting: I did eventually get a repro in 60.0.3112.113, so either this is a bug that's been fixed since then, or it's a bug that only reproduces in certain configurations of PlzNavigate/SiteIsolation.

file:///C:/Users/elawrence/Desktop/frame-ancestors.aspx.html
Refused to display 'https://bayden.com/test/csp/Frame-Ancestors-File.aspx' in a frame because an ancestor violates the following Content Security Policy directive: "frame-ancestors file: https://bayden.com".

Confirmed. The problem also repros in 61.0.3163.79 until you change chrome://flags/#enable-site-per-process to "Enabled" at which point the repro goes away.

Thanks for looking at this, Eric. Much appreciated !

Here is some more info from a customer experiencing the issue :

Could not reproduce :

CHROME - Windows Version 60.0.3112.113 (Official Build) (64-bit) - Latest
on Aug 29

Reproduced :

CHROME - MAC Version 60.0.3112.113 (Official Build) (64-bit) - Latest on
Aug 29

I've now verified that this issue reproduces in Chrome 60, 61, and 63 on Windows and Mac based on the state of chrome://flags/#enable-site-per-process.

Interestingly, Site-Per-Process is not enabled by experiment on Stable at this time, so I'm not sure why the user mentioned in comment #11 is seeing something different (unless they're the sort of person who manually manipulates chrome's flags).

Assigning to dcheng@ for the time being based on comment #12

It's worth mentioning that enabling enable-site-per-process seems to fix the problem, so this seems less likely to be an issue in isolation itself. The repro steps in #c8 should simplify the root-causing.

We ought to be looking at the parent frame's URL, not the origin; I can imagine that there are some cases in which the origin isn't correctly round-tripping through the remote frame (see https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/csp/CSPDirectiveList.cpp?rcl=4feeb468861a02b72083829623fce8b8a66e908c&l=269).

That said, it's not at all clear why turning site-per-process on would fix it. It seems like the opposite should be the case? Weird.

In any event, Andy's better positioned to do an initial evaluation of what we're seeing in Blink than Daniel. We can loop in oopif folks if need be.

It seems that there has been a conscious decision to use the origin instead of the URL because of remote frames which don't have access to the URL in the first place and it was deemed ok because frame-ancestors checks only use the origin anyway.

The problem is that for local origins (such as ones that have a "file:" scheme) we set a flag here https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Document.cpp?l=6074 which is supposed to block access from other local origins. But the way it is checked here https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/weborigin/SecurityOrigin.cpp?l=428, it checks again for the origin being accessed to see if it's local (which we already know it is because the flag was set... hell there's even a DCHECK on the function that sets the flag). This means basically that we can't actually get the string representation for any local origin...

I'm still not clear why enable-site-per-process makes it work, debugging is difficult because I actually need --single-process but from the little printf debugging I could do, it seems that the "block_local_access_from_local_origin_" flag that is used to keep track of the setting gets lost somewhere along the way.

Take all of the above with a grain of salt, it's the first time I'm seeing most of this code and I could have missed lots. My opinion is that the blocklocalaccessfromlocalorigin does not actually work the way it's expected and it block all access and we could perhaps just get rid of it? :D.

mkwst@ - what do you think of the wall of text above

ian.melven@ - As a side note, frame-ancestors '*' won't work because it does not actually match the 'file:', only network schemes and the current scheme (but 'frame-ancestors file:' would have worked if not for this bug)

@andypaicu thanks for letting me know, that is very helpful for us.