[security] OpenID identity leaks

Mon Dec 30 20:08:09 UTC 2013

Its not clear to me why fragment identifiers make the problem of open
redirects even worse than they are. What additional information is lost, or
alternatively how does this make the attack easier for a malicious party?

As for rp discovery, i did do a bit of a survey around the idps to check,
and i do recall a number of them took the approach that if the rp wasnt
discoverable then oh well, but if it was and the return to didnt match then
they would reject the request. Which seems sensible.
On Dec 31, 2013 3:12 AM, "Andris Atteka" <andris.atteka at gmail.com> wrote:

> Hi Johnny,
>
> yes, mandatory RP discovery would help here, however as you correctly
> pointed out, it's not widely used.
>
> I'll try to explain the issue I'm raising more detailed:
>
> Browsers preserve URL fragment across HTTP redirects, e.g.
> https://www.google.com/search?btnI&q=allinurl%3A%2F%2Flva.lv#fragment
>
> If fragment identifier is included in the return_to, OP will attach OpenID
> parameters only after the fragment identifier (and these will be preserved
> across the redirect to a malicious site). So to exploit this, attacker
> would have to find an open redirector in RP's domain.
> Of course the same can be achieved with an XSS in RP's domain. Open
> redirectors however are much more common and not even considered a security
> issue by some.
>
> I was just wondering why so many OPs allow fragment identifier in
> return_to (e.g. here's another one - https://pip.verisignlabs.com/)? Is
> there some intended functionality?
>
> Regards,
> Andris
>
>
> On Wed, Dec 25, 2013 at 11:52 PM, Johnny Bufu <johnny.bufu at gmail.com>wrote:
>
>> Andris this looks exactly like the realm/return URL spoofing described on
>> the OpenID wiki page. I tried the link and the Google OP prompted me that a
>> Google RP wants my email address, then I ended up at your (I assume)
>> non-google RP - where I was told I shouldn't have trusted the Google RP.
>> User interaction & approval at the OP was required.
>>
>> There is a mitigation option for this, however it is not widely adopted.
>> RPs can publish their "RP identity" discovery information, and OPs can
>> chose to only interact with RPs that published discovery information, and
>> only respond to requests for which the return URL matched the RP's
>> discovery information.
>>
>> http://openid.net/specs/openid-authentication-2_0.html#rp_discovery
>>
>> This feature however is not widely deployed to my knowledge, and an OP
>> choosing to adopt this policy would have quite a few interoperability
>> issues.
>>
>> Johnny
>>
>>
>> On 13-12-21 02:35 AM, Andris Atteka wrote:
>>
>>> Hi Bart,
>>>
>>> Thanks for your response, however this case is a bit different from what
>>> you are describing.
>>> If you try the link I sent out, you'll notice that identity is leaked
>>> before any user action.
>>>
>>> Regards,
>>> Andris
>>>
>>>
>>> On Sat, Dec 21, 2013 at 12:07 PM, Bart van Delft <bartvandelft at yahoo.com
>>> <mailto:bartvandelft at yahoo.com>> wrote:
>>>
>>>     Hi Andris,
>>>
>>>     What you suggest sounds a bit like realm spoofing? In that case it
>>>     is a known vulnerability of OpenID:
>>>     http://wiki.openid.net/w/page/12995216/OpenID_Phishing_Brainstorm
>>>
>>>     Best regards,
>>>
>>>     Bart van Delft
>>>
>>>
>>>     On 2013-12-21 10:12, Andris Atteka wrote:
>>>
>>>>     Hi Everyone,
>>>>
>>>>     Google's Security Team suggested to ask this question here.
>>>>
>>>>     Attacker can perform the following steps:
>>>>     1) Find an open redirect in some major website that leads to
>>>>     attacker's website (and append fragment identifier to this URL)
>>>>     2) Craft a URL and set redirect_url to the open redirect
>>>>     3) Trick the victim into visiting the URL
>>>>     As the URL belongs to a major website, most likely victim will
>>>>     accept the RP and his identity will be leaked to attacker's site.
>>>>
>>>>     Here's an example (Google itself has some nice open redirects):
>>>>     https://www.google.com/accounts/o8/ud?openid.claimed_
>>>> id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_
>>>> select&openid.ext0.mode=fetch_request&openid.ex
>>>>     t0.requ
>>>>     ired=email&openid.ext0.type.email=http%3A%2F%2Faxschema.
>>>> org%2Fcontact%2Femail&openid.identity=http%3A%2F%2Fspecs.openid.net
>>>> %2Fauth%2F2.0%2Fidentifier_select&openid.mode=checkid_setup&openid.ns=
>>>> http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.ns.ext0=
>>>> http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ns.ui=http%3A%2F%
>>>> 2Fspecs.openid.net%2Fextensions%2Fui%2F1.0&openid.realm=https%3A%2F%
>>>> 2Fwww.google.com%2F&openid.return_to=https%3A%2F%2Fwww.google.com
>>>> %2Fsearch%3FbtnI%26q%3Dallinurl%253A%252F%252Flva.
>>>> lv%23aaa&openid.ui.icon=true&openid.ui.lang=en-US&openid.
>>>> ui.mode=popup&third_party_login=false
>>>>      <https://www.google.com/accounts/o8/ud?openid.claimed_
>>>> id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_
>>>> select&openid.ext0.mode=fetch_request&openid.ext0.required=
>>>> email&openid.ext0.type.email=http%3A%2F%2Faxschema.org%
>>>> 2Fcontact%2Femail&openid.identity=http%3A%2F%2Fspecs.
>>>> openid.net%2Fauth%2F2.0%2Fidentifier_select&openid.
>>>> mode=checkid_setup&openid.ns=http%3A%2F%2Fspecs.openid.net%
>>>> 2Fauth%2F2.0&openid.ns.ext0=http%3A%2F%2Fopenid.net%2Fsrv%
>>>> 2Fax%2F1.0&openid.ns.ui=http%3A%2F%2Fspecs.openid.net%
>>>> 2Fextensions%2Fui%2F1.0&openid.realm=https%3A%2F%
>>>> 2Fwww.google.com%2F&openid.return_to=https%3A%2F%2Fwww.
>>>> google.com%2Fsearch%3FbtnI%26q%3Dallinurl%253A%252F%
>>>> 252Flva.lv%23aaa&openid.ui.icon=true&openid.ui.lang=en-
>>>> US&openid.ui.mode=popup&third_party_login=false>
>>>>
>>>>
>>>>     This can even be extended so that user doesn't have to accept RP.
>>>>     For this attacker would have to find an open redirect that shares
>>>>     domain with some valid OpenID consumer (some major sites actually
>>>>     do this). In this case user wouldn't even notice the identity leak.
>>>>
>>>>     Is this only a bug in Google's OpenID implementation or a bug in
>>>>     the OpenID spec itself?
>>>>
>>>>     I do see the OpenID spec talking about normalization of
>>>>     identifiers (including removal of fragment and fragment
>>>>     identifier). Does the same apply to redirect_url? If not, would it
>>>>     be reasonable to include this in the spec?
>>>>
>>>>     Regards,
>>>>     Andris Atteka
>>>>     andrisatteka.blogspot.com <http://andrisatteka.blogspot.com>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     security mailing list
>>>>     security at lists.openid.net  <mailto:security at lists.openid.net>
>>>>     http://lists.openid.net/mailman/listinfo/openid-security
>>>>
>>>
>>>
>>>     _______________________________________________
>>>     security mailing list
>>>     security at lists.openid.net <mailto:security at lists.openid.net>
>>>
>>>     http://lists.openid.net/mailman/listinfo/openid-security
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> security mailing list
>>> security at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-security
>>>
>>>
>
> _______________________________________________
> security mailing list
> security at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20131231/1d18685f/attachment-0001.html>