-
-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CSP: block WebRTC #479
CSP: block WebRTC #479
Conversation
Is it implemented by any browsers yet? |
Not yet, unfortunately. I expect Chromium will implement this. I think it'll be an important directive since WebRTC does not go through Fetch. Closing this loophole was one of the most demanded CSP features in the past. |
Upon further inspection: Permissions-Policy can already block WebRTC.
I'll ask some webappsec folks about the logic behind adding the CSP
directive in light of Permissions-Policy and report back.
|
It looks like this is unnecessary, given that the Permissions-Policy already blocks WebRTC. |
I don't think there's a Permissions-Policy setting for WebRTC itself. |
w3c/webappsec-permissions-policy#250 This issue seems to indicate that there is no webrtc Permissions-Policy |
[@]dveditz:mozilla.org shared some info from the `#security:mozilla.org` Matrix room:
found the difference -- Permission-policy controls things that request permissions, so it covers the camera and microphone getUserMedia() requests used in WebRTC. That doesn't prevent the connections though so that's why people want to add webrtc to CSP. That's a fairly recent addition (it's in the editor's draft, but not in the year-old published working draft) and may or may not be the best place to restrict it.
Some of the https:// fetches (to get peer info from an ICE server, for example) might get blocked by connect-src, though it's not very clear to me which circumstances do or don't in the Firefox implementation at a fairly quick look. The DTLS communication is definitely not covered by fetch-centric CSP without something like this new proposal.
Direct link: https://matrix.to/#/!anEyEXBYVSlveMBsbt:mozilla.org/$8cPpnG-rvikEOwSTRVY-v_C-msCIQKaDZY2egDRy86Q?via=mozilla.org&via=matrix.org&via=kde.org
Honestly, I think that simply blocking JS from the subset of pages that don't need it would be a much more robust solution in the meantime.
|
f68494a
to
b0b84a0
Compare
c6701d3
to
66132ef
Compare
@Seirdy We had to rebase the repository to fix some commit messages for a legal reason. Can you rebase this? |
Merged to the webappsec-csp repo in April: w3c/webappsec-csp#457
On Fri, Aug 12, 2022 at 07:34:15AM -0700, terezipyrope wrote:
w3c/webappsec-permissions-policy#250
This issue seems to indicate that there is no webrtc Permissions-Policy
Ah, I missed that. A full list of all implemented PP directives are in https://chromedevtools.github.io/devtools-protocol/tot/Page/#type-PermissionsPolicyFeature.
(side-note: hot damn this header is massive...almost 1.4kb just to opt-out of everything).
|
8faae51
to
35468ab
Compare
c70441d
to
fcbce2d
Compare
dea31f5
to
d7eacfb
Compare
6ca4922
to
14ce3de
Compare
283f8fe
to
85afa18
Compare
beaf7c9
to
6ae13d7
Compare
4b05c91
to
65ced09
Compare
This is implemented now. |
Merged to the webappsec-csp repo in April:
w3c/webappsec-csp#457