X-Frame-Options is ignored on redirection status-codes without a location header (unlike CSP frame-ancestors)
Categories
(Core :: DOM: Security, defect, P3)
Tracking
()
People
(Reporter: jannis, Unassigned)
References
Details
(Keywords: sec-low, Whiteboard: [domsecurity-backlog3])
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0
Steps to reproduce:
The X-Frame-Options header is ignored when the response status-code is one of 300, 301, 302, 303, 307 or 308. Even if the location header is not set.
Visit: https://demo.websec.saarland/static/xfo.html and observe the (non)-blocking of responses.
Actual results:
XFO: deny is not applied when the response code is a redirection response code and no location header is present.
CSP: frame-ancestors 'none'; is applied in this case.
When a location header is present, both responses do not get blocked.
Expected results:
According to https://bugs.chromium.org/p/chromium/issues/detail?id=835465 not blocking server-side redirections with XFO and frame-ancestors is currently the wanted behavior.
However, Firefox also does not block responses with a redirection status-code when no location is present for XFO.
Firefox should block these responses as no redirection happened (and to be compatible with frame-ancestors and chrome).
Updated•4 years ago
|
Comment 1•4 years ago
|
||
This doesn't need to be hidden given the public chrome bug and low severity. One could even argue this is correct, because if there's no Location: header the 30x body is usually supposed to contain the destination link for a "manual" redirect, and how does that work if you block it? On the other hand, blocking it is safer than not and since Chrome is doing this already we don't risk breaking anything.
Updated•4 years ago
|
Comment 2•4 years ago
|
||
The severity field is not set for this bug.
:ckerschb, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•4 years ago
|
Description
•