1969154 - CSP fails to enforce path-based restrictions on iframe sources

Status: RESOLVED DUPLICATE of bug 1808979

(Core :: DOM: Security, defect)

Description

[Nikolaos Mourousias]

Attachment: index.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0

Steps to reproduce:

Serve the attached HTML file to Firefox using a simple HTTP server (python -m http.server).
Notice the first two iframes fail to load, while the last one does.

The allowed resource path defined in the CSP is http://127.0.0.1:8000/app/ (imagine an SPA), but access to the path http://127.0.0.1:8000/transfer/confirm (imagine a confirmation page) is mistakenly allowed.

Tested on both stable and nightly.

Actual results:

CSP fails to enforce path-based URL rules on same-origin iframes.

The bug occurs when the src attribute of an already-existing iframe is updated to a disallowed path or when the iframe (after loading initially) is redirected to a blocked sub-resource (using an open-redirect website bug, for example).

The bug doesn't occur when the iframe parsed and loaded, already contains its source URL.

Expected results:

All 3 iframes should have been blocked from loading. I additionally verified this using Chrome.

Comment 1

[Nikolaos Mourousias]

Attachment: firefox.png

Comment 2

[Nikolaos Mourousias]

Attachment: chrome.png

Comment 3

[Daniel Veditz [:dveditz]]

The bug occurs when [...] or when the iframe (after loading initially) is redirected to a blocked sub-resource

The redirect variant is specified behavior and should work the same on Chrome and safari. It's a "damned if you do, damned if you don't" compromise, and means that if your CSP depends on paths for protection then you need to use enough paths on all your entries to avoid open redirects on your partner sites.
https://w3c.github.io/webappsec-csp/#source-list-paths-and-redirects

Still investigating the other parts.

Comment 4

[Nikolaos Mourousias]

Sorry for the confusion, I wasn't aware of that part of the spec.
Indeed, when a redirect occurs from a 30X status code, both Firefox and Chrome are spec compliant and they both load the redirected page, even if disallowed by the CSP.

What I actually had in mind when I originally mentioned the redirect variant, was when the redirection occurs after that page was fetched (client-side redirect). This could be as part of a simple location=inject or injection into a meta refresh tag. Under that scenario, Chrome blocks the redirection, Firefox doesn't.

Example:

<iframe src="http://127.0.0.1:8000/app/redir.php?0=/transfer/confirm"></iframe>

with redir.php being:

<script>
location="<?php echo $_GET[0] ?>";
</script>

Either way, I assume all this behavior might be caused by the same underlying bug.
Thanks for taking a look!

Comment 5

[Daniel Veditz [:dveditz]]

Attachment: expanded testcase

Minor variation of the reporter's testcase:

• added logging of the securitypolicyviolation events
• added a fourth frame to test navigating via links

In terms of blocking, Chrome and Safari agree on blocking everything in the testcase except clicking on the "Allowed" link in the final frame. Firefox loads the 3rd frame as the reporter says, and also doesn't block the "Not allowed" link in the 4th frame I added (it does correctly block the example.org link)

A minor difference on the blocked link navigations: chrome navigates to their blocked-frame error page, while both Firefox and Safari do nothing as if they were invalid links. Chrome's behavior is more consistent with the general philosophy of treating CSP blocks as "network errors", but I couldn't figure out where this was specified for navigating inside a frame. It's quite possible Firefox's behavior in the link case is because we're treating scripted navigations as equivalent to redirects. We have in some other cases because the potential for security info leaks is similar, but I'd have to do some bug spelunking to see if that's the case here. Maybe file a CSP spec bug about the platform inconsistency?

Comment 6

[Daniel Veditz [:dveditz]]

Maybe file a CSP spec bug about the platform inconsistency?

That's directed at myself and my colleagues. Please don't file a public spec issue until we get to the bottom of this.

After some more experimenting I do think this is us treating these as "scripted" redirects. In your second frame .src is set before the frame element is added to the document, which is what triggers the load. So that's an initial load and not a navigation. In third case where we don't match Chrome or Safari the iframe has already loaded "about:blank" before you set .src, so that does get treated as a navigation.

Any thoughts on this, Tom?

Comment 7

[Tom Schuster]

This might be related to bug 1808979?

Comment 8

[Tom Schuster]

See bug 1808979 comment 2. Setting the about:config pref security.csp.truncate_blocked_uri_for_frame_navigations to false, which disables this code, fixes this issue.