Re: setIdentityProvider question

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.



> 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.

-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:12:11 UTC