W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2013

Re: setIdentityProvider question

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Mon, 12 Aug 2013 13:17:04 +0100
Message-ID: <5208D240.3020504@cs.tcd.ie>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC