1920348 - CSP bypass in DevTools Network Tab Response Preview because `content-security-policy:` headers ignored

Status: RESOLVED FIXED

(DevTools :: Netmonitor, defect, P2)

Description

[Satoki Tsuji]

Attachment: poc.py

CSP (Content Security Policy) is a crucial security feature set by web administrators to prevent information leakage from users. When clicking on a network request in the DevTools Network tab and viewing the response preview, it becomes evident that CSP is not enforced. This behavior does not occur with the <meta> tag.

I have attached poc.py. Upon inspecting the site, you can see that the CSP is set to default-src 'none';, and elements such as base, img, and iframe are prohibited. However, what happens when a user opens the response preview in the Network tab? CSP is immediately disabled, and a request for the content within the base tag is triggered.

This illustrates a case of HTML injection, where CSP fails to protect if sensitive information (such as UUIDs) is included in the URL path. In other words, the path gets leaked. Additionally, it demonstrates that content may be rendered incorrectly as well.

Comment 1

[Satoki Tsuji]

Attachment: test.png

A weird preview

Comment 2

[Julian Descottes [:jdescottes]]

Thanks for filing.

The preview displayed in the netmonitor is not actually showing the exact same page as the one loaded in your tab. It is an iframe using a data URI to look like the retrieved HTML. So it sounds unlikely that requests initiated from this iframe will be able to leak critical information? But maybe I am wrong, did you build a test case which really illustrates a leak ?

Let us know,
thanks

Comment 3

[Satoki Tsuji]

Thank you for your reply.
At first glance, it may seem like there’s no information leakage. I initially thought the same. Since JavaScript doesn’t execute, it seems safe against XSS. However, the key point to note here is that this bug bypasses CSP, allowing CSS injection and network requests to be issued. In Chrome, requests from the developer tools preview are completely blocked.

A simple case of information leakage involves exposing paths like those in the img tags. Similar to CVE-2022-40956, which I previously reported, the URL path meant to be hidden is leaked due to the use of the base tag. (poc1.py)
A more dangerous scenario is that CSS injection can be freely executed. Even if CSP is set to block all loads (set to none), elements in the HTML can be leaked via CSS injection. Even though CSS injection is blocked when accessing `http://localhost:31415/?cssi=<style>input[value^="e.g_csrftoken"]{background:url(http://localhost:31415/omg) !important;}</style>`, when previewed from the network tab, 'OMG' is printed on the server console. This indicates that the CSS injection was successful. In the poc, it's represented as a string, but it's generally known that individual characters can be leaked one at a time per access. (poc2.py)
An interesting behavior, though I’m not sure if it qualifies as a vulnerability, is that by using the meta tag, I was able to redirect the user to a site different from the actual one.

Comment 4

[Satoki Tsuji]

Attachment: poc1.py

Comment 5

[Satoki Tsuji]

Attachment: poc2.py

Comment 6

[Satoki Tsuji]

This is a supplementary video and tool for CSS Injection. Various values such as CSRF tokens can be retrieved. (The amazing work of other hackers)
https://www.youtube.com/watch?v=06gHFGbhTGY
https://github.com/m---/onsen

Comment 7

[Daniel Veditz [:dveditz]]

(In reply to Satoki Tsuji from comment #0)

CSP (Content Security Policy) is a crucial security feature set by web administrators to prevent information leakage from users.

Content Security Policy is intended to prevent content injection; it is not designed to prevent information leakage and there are several known gaping holes that make it a poor tool for that use. The fervent wishes of web administrators don't change the reality of CSP.

That said, ignoring CSP headers means that content injection is possible. Pretty far-fetched as an attack, though.

Comment 8

[Julian Descottes [:jdescottes]]

We should try to re-apply CSP headers in our preview, the csp attribute on iframes could be a way to do that, but it's not supported on Firefox yet. https://bugzilla.mozilla.org/show_bug.cgi?id=1857140.

Alex, can you check if we have privileged apis to do the same?

Comment 9

[Daniel Veditz [:dveditz]]

(In reply to Julian Descottes [:jdescottes] from comment #8)

We should try to re-apply CSP headers in our preview, the csp attribute on iframes could be a way to do that, but it's not supported on Firefox yet

Or don't let content in the preview pane load anything else at all whether it's got a CSP or not?

I don't know if we will ever get around to implementing the "Embedded Enforcement" spec, but it wouldn't help you here. If a site could impose a CSP on another site's content it could be used to selectively disable parts of the page such as validation scripts--it would become a security-breaking tool instead of security-enhancing. CSP-EE therefore requires that the framed site respond with the CSP you're trying to enforce as an "opt-in". If it does then it's all good -- the parent site is assured the framed content has the required CSP. If it does not then our only choice is to block the content and not show it. That would defeat the purpose of a DevTool panel that's trying to render the content.

Comment 10

[Satoki Tsuji]

How's the progress on this bug? There's no urgent need to fix it right away, but I'm interested in any updates.

Comment 11

[Satoki Tsuji]

Hello, I have a feeling that this bug is not valid in the latest version. When was it fixed? I think it was an unintentional fix in the process of fixing another bug. I'm happy about it, but I'm a little unhappy.

Comment 12

[Tom Schuster]

We didn't really fix this.

We accidentally applied a strict CSP to the preview in bug 1943360, so your test case seems fixed in Firefox 137. This strict CSP caused complaints, so we had to removed that again in Firefox 138 (bug 1957333).

Comment 13

[Satoki Tsuji]

omg. I thought this issue was resolved. Sorry. All I want to say is that if the security risk is resolved then all is well.

Comment 14

[Tom Schuster]

Attachment: Bug 1920348 - Apply CSP header to the HTML Preview. r?jdescottes

Comment 15

[Tom Schuster]

Hi! Considering that I already looked at this recently in bug 1957333 I think I was able to come up with a solution. My problem is that while testing manually responseHeaders seems to work correctly for me in HtmlPreview, but during the test run of devtools/client/netmonitor/test/browser_net_html-preview.js the value of responseHeaders is undefined. Maybe because it is using fetch? (I am also curious how responseHeaders.headers works with duplicate headers)

Comment 16

[Julian Descottes [:jdescottes]]

Thanks for looking at this bug! I added some comments to answer your questions in the patch.

Comment 17

[Tom Schuster]

Attachment: Bug 1920348 - ChromeUtil for creating a nsIContentSecurityPolicy from a header string. r?freddyb,simonf

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/a57982ee343f
ChromeUtil for creating a nsIContentSecurityPolicy from a header string. r=simonf
https://hg.mozilla.org/mozilla-central/rev/3691752b223d
Apply CSP header to the HTML Preview. r=jdescottes,devtools-reviewers

Comment 19

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/a57982ee343f
https://hg.mozilla.org/mozilla-central/rev/3691752b223d

Comment 20

[Daniel Veditz [:dveditz]]

Lowering the severity to sec-low: scripts would never run with or without CSP.

Comment 21

[Jesse Schwartzentruber (:truber)]

Attachment: advisory.txt