1864434 - CSP header is reset by multipart/x-mixed-replace

Status: NEW

(Core :: DOM: Security, defect, P3)

Description

This was reported on twitter by @ankursundara.

We seem to treat the new content loaded by Content-Type: multipart/x-mixed-replace like a new load and don't keep the previous Content-Security-Policy header. This means that the CSP can be weakened, but only when the attack already controls all headers (actually the whole response).

I think we can either:

1. Do nothing
2. Look into removing multipart/x-mixed-replace
3. Removing it only for non-images (MJPEG?)
4. Only allow adding new CSP policies

Comment 1

[Frederik Braun [:freddy]]

I think we should add a UseCounter to see how often multipart/x-mixed-replace is used to help inform the case for 2 vs. 3.
In the meantime, we could try and plug the holes in CSP as introduced by x-mixed-replace support here by supporting append-only.

Comment 2

[johanaxelcarlsson]

Hi team!

I looked into this a bit after reading about it. It looks like the CSP headers are actually "merged" and not overwritten.

If the original response has its own Content-Security-Policy: script-src the bypass does not work. The example on Twitter shows how the response only has a Content-Security-Policy: default-src 'none' leaving script-src to be declared by the body of the response.

If you change the example to have Content-Security-Policy: script-src 'none' in the main response then there is no way to bypass it later.

Could still be an issue, but not as bad as "bypass CSP". Its more a CSP alteration if the CSP is missing fields.

Hope that helps!

Test it here:
Can not override: https://joaxcar.com/firefox/test.php
Can add script src: https://joaxcar.com/firefox/test2.php

Comment 3

[Frederik Braun [:freddy]]

We should get to this soon.

Comment 4

[Daniel Veditz [:dveditz]]

The example on Twitter shows how the response only has a Content-Security-Policy: default-src 'none' leaving script-src to be declared by the body of the response.

a policy that has default-src 'none'; with no script-src directive has an effective script policy of script-src 'none';. If the two headers are both enforced (option 4 in comment 0) then your two scenarios should be equivalent.

Comment 5

[Masato Kinugawa]

Attachment: fx_x-mixed-replace_csp_script-src-elem.php

(In reply to johanaxelcarlsson from comment #2)

Could still be an issue, but not as bad as "bypass CSP".

You can merge script-src-elem 'unsafe-inline' (or script-src-attr) and bypass CSP even if there is script-src 'none' in the original response. I created the PoC: https://vulnerabledoma.in/fx_x-mixed-replace_csp_script-src-elem.php

Since the script-src-elem / script-src-attr is not used often, I think it is likely to lead to bypass in most cases. Actually, I have encountered such a bypass case in a pentest.