Re: [CSP2] browser behavior on frame-ancestors violation through previous iframe content navigation

Hi,
Sorry, but I completely overlooked that CSP spec was already stating what I was asking for. (In short, on frame ancestor violation, either act as receiving a blank page, or display an error page.)
It was instead a chromium non conformance issue.
Please ignore my previous message.

Regards,

Frédéric.

----- Mail original -----
De: fredericdelaporte@free.fr
À: public-webappsec@w3.org
Envoyé: Vendredi 4 Septembre 2015 23:50:15
Objet: [CSP2] browser behavior on frame-ancestors violation through previous iframe content navigation

Hi,

Let have a page A iframing a page B, which contain a simple link (a href) to a page C.
Let CSP frame-ancestors allow framing of B in A, but disallow framing of C in A.

Browsing A, what should be a sound browser behavior when clicking link to C?

Current Chrome and Firefox behavior seems to be 'abort navigation', without any UI message.
This seems in accordance to navigate spec ( http://www.w3.org/TR/html5/browsers.html#navigate ).

My issue here is about CSP used for preventing clickjacking on sensitive pages (the C one), while allowing framing on other pages (the B one).

Not telling anything to the user as for why the navigation got canceled seems to me as detrimental to the user experience and B site reputation in this use case. Current behavior cause the B page to look broken, without much solution as far as I know if A page (potentially from some malevolent site) sandbox the iframe to forbid top navigation.

The navigate spec allows to navigate to a new top window instead, but this is not current choice of Chrome and Firefox for the specific case of frame-ancestors. While for some other cases, it is. (In Chrome, if A forbid top navigation on iframe, a link in B with target="_top" does navigate to a new top window.)

May the spec for frame-ancestors give some specific recommendations on browser UI behavior on violations, like favoring the navigation to a new top window?

Regards,

Frédéric

Received on Monday, 7 September 2015 14:30:36 UTC