search

w3c / webappsec-permissions-policy

A mechanism to selectively enable and disable browser features and APIs
https://w3c.github.io/webappsec-permissions-policy/
Other
396 stars 154 forks source link

What happened to the webrtc feature? #250

Open danjenkins opened 5 years ago

danjenkins commented 5 years ago

I can see that the original webrtc feature got pulled into two separate things (getUserMedia and webrtc) but now webrtc doesn't exist? Can someone explain why? Came across some third party code on a website the other day (they're investigating but I expect its from a dependency of a dependency) that was using the RTCPeerConnection API (among loads of others) to fingerprint users - the original website owner say they don't have a need to fingerprint users so I can only assume they didn't mean for this to happen and I immediately thought of feature policies being able to stop use of the WebRTC APIs - I see midi and usb are included; why wouldn't we stop the use WebRTC apis too?

Malvoz commented 5 years ago

CSP? https://github.com/w3c/webappsec-csp/pull/287

clelland commented 5 years ago

I don't actually know enough about WebRTC to know whether this makes sense or if restricting RTCPeerConnection is sufficient, but if so, we should add that back as a feature. @henbos -- can you comment on the feasibility of a policy here?

henbos commented 5 years ago

I think @alvestrand knows the context better.

lgrahl commented 5 years ago

As discussed in the PR, we should at least consider an on/off switch and I'd prefer having this sooner than later. We can still improve on it later.

Malvoz commented 5 years ago

It seems from rather quickly reading the CSP PR comments that the issue lies in not being able to scope src to adress literals? I'm in no position to say if CSP can adopt parametric features, but that shouldn't be an issue for Feature Policy?

clelland commented 5 years ago

CSP seems best suited for declaring what resources a page is allowed to connect to; while a boolean switch would be a good fit for feature policy, especially if the intent is to also extend restrictions into child frames.

My only question is whether blocking use of RTCPeerConnection is enough, or if there are other interfaces that also need to be included.

And actually, that doesn't need to be worked out here; a PR to https://github.com/w3c/webrtc-pc can define the feature, and call into https://html.spec.whatwg.org/#allowed-to-use as necessary. If that's adopted, we can update https://github.com/w3c/webappsec-feature-policy/blob/master/features.md with a link to the relevant text.

lgrahl commented 5 years ago

Basically, the problem is that connectivity checks sent by WebRTC contain a small amount of custom data and can contain arbitrary IP addresses to establish a direct connection (see https://github.com/w3c/webappsec-csp/pull/287#issuecomment-366446690). I currently do not see a way to constrain that.

See this demo for an example to leak unsecured data to an IP of your choice.

And actually, that doesn't need to be worked out here; a PR to https://github.com/w3c/webrtc-pc can define the feature, and call into https://html.spec.whatwg.org/#allowed-to-use as necessary. If that's adopted, we can update https://github.com/w3c/webappsec-feature-policy/blob/master/features.md with a link to the relevant text.

Thanks for that info. @alvestrand, should we pick this up in webrtc-pc then?