- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Mon, 25 Nov 2013 15:09:27 -0500
- To: public-webrtc@w3.org
On 25/11/2013 2:46 PM, Harald Alvestrand wrote: > From draft-ietf-rtcweb-security-05.txt: > > 4.1.1. Threats from Screen Sharing > > In addition to camera and microphone access, there has been demand > for screen and/or application sharing functionality. Unfortunately, > the security implications of this functionality are much harder for > users to intuitively analyze than for camera and microphone access. > (See > http://lists.w3.org/Archives/Public/public-webrtc/2013Mar/0024.html > for a full analysis.) > > The most obvious threats are simply those of "oversharing". I.e., > the user may believe they are sharing a window when in fact they are > sharing an application, or may forget they are sharing their whole > screen, icons, notifications, and all. This is already an issue with > existing screen sharing technologies and is made somewhat worse if a > partially trusted site is responsible for asking for the resource to > be shared rather than having the user propose it. http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html should help with oversharing, especially with a pulsing border and a tooltip to explain what it means. > A less obvious threat involves the impact of screen sharing on the > Web security model. A key part of the Same Origin Policy is that > HTML or JS from site A can reference content from site B and cause > the browser to load it, but (unless explicitly permitted) cannot see > the result. However, if a web application from a site is screen > sharing the browser, then this violates that invariant, with serious > security consequences. For example, an attacker site might request > screen sharing and then briefly open up a new Window to the user's > bank or Gmail account, using screen sharing to read the resulting > displayed content. A more sophisticated attack would be open up a > source view window to a site and use the screen sharing result to > view anti cross-site request forgery tokens. I don't understand how/why screen sharing allows one to violate the Same Origin Policy. If I access http://www.google.com/, and it begins screen-capturing, and tries opening http://www.bank.com/, won't the act of opening http://www.bank.com/ check the Same Origin Policy? Meaning, if bank.com doesn't want to allow Cross Origin requests, then google.com won't be able to open it nor capture its contents. Gili > > These threats suggest that screen/application sharing might need a > higher level of user consent than access to the camera or microphone. > > I think it would be good to formulate suggestions for changes here in > a way that suggest changes to this text, if changes are warranted. > > > On 11/25/2013 05:56 PM, cowwoc wrote: >> Hi, >> >> In the WebRTC World conference Justin Uberti mentioned that Chrome >> (and Firefox too?) will be moving screen sharing out of Javascript, >> requiring developers to publish a browser extension per application >> that wishes to screen-share. The logic behind it was that malicious >> app could be banned from the app store. >> >> One thing I didn't understand (and was not explained) is why screen >> sharing is substantially more security-sensitive than webcam sharing? >> I get the fact that someone could use screen sharing to snoop on my >> banking activity, but how is this any more security sensitive than >> knowing what I look like and where I live? If the security dialog is >> good enough for webcam sharing, why is it not good enough for screen >> sharing? >> >> And finally, couldn't you simply require the use of SSL for this >> feature and then ban malicious applications based on their >> certificate? Requiring the download of an extension is almost like >> requiring a browser plugin for WebRTC. I'd like to avoid it if at all >> possible. >> >> Thanks, >> Gili >> > >
Received on Monday, 25 November 2013 20:10:27 UTC