- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Mon, 12 Aug 2013 13:17:04 +0100
- To: Eric Rescorla <ekr@rtfm.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 08/12/2013 01:11 PM, Eric Rescorla wrote: > On Mon, Aug 12, 2013 at 4:56 AM, Stephen Farrell > <stephen.farrell@cs.tcd.ie>wrote: > >> >> Hi, >> >> I've a question about this function. [1] >> >> If I've read it right, it allows a site to tell a browser to use >> a given IdP, which sounds useful. >> >> However, what if that site isn't nice or has been hacked and e.g. >> tells a browser to use paypa1.com (or some other look-alike/cousin >> domain)? That'd seem to be a nice phishing vector. >> >> Perhaps section 8.2.2 should contain a MUST for browsers to do >> something special in the chrome for a provider value that its >> never seen before? Or, are there other mitigations that'd avoid >> or detect the problem? >> > > Well, this is exactly the experience when you are asked to log > into a site via Facebook connect. I.e., the attacker can simulate > your not being logged into FB and then prompt for your FB > password. This is done entirely in content. > > So, while I agree this is a good phishing vector, it's kind of one > we opened up a while ago. But isn't there a chance here to do a bit better since the browser gets a look-in before the IdP proxy is loaded? Could be that's not worthwhile (given that the bad site could try phish without doing any webrtc stuff) but OTOH perhaps raising the bar a bit here would be doable. I'd guess that being asked to login via a new IdP should be relatively uncommon for webrtc. >> I also wondered about how i18n is handled when a DOMString is >> interpreted as a domain name. That's documented somewhere else >> I guess and shouldn't be here, but maybe a reference would be >> a good idea (it'd help me at least). >> > > I'll see what I can do. Ta, S. > > -Ekr > > >> Apologies in advance if this has been discussed - I didn't see >> it in the (voluminous:-) archive. >> >> Cheers, >> S. >> >> PS: I may have more questions, we're using webrtc as a case >> study in a small FP7 security project. [2] If there're areas >> of the spec that could use some more security eyeballs, then >> feel free to point me at those (offlist I guess). >> >> [1] >> >> http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcpeerconnection-interface-extensions-3 >> >> [2] http://www.strews.eu/ >> >> >
Received on Monday, 12 August 2013 12:17:30 UTC