[security] OpenID identity leaks

Thu Jan 2 10:17:29 UTC 2014

URL fragment isn't sent to the server, but a malicious party can extract it
with client side javascript. Please see the POC I sent out earlier.

Interestingly, I found this old thread where it's suggested to use fragment
identifier in return_to for performance optimization:
http://lists.openid.net/pipermail/openid-specs/2009-March/005694.html

Regards,
Andris

On Tue, Dec 31, 2013 at 12:59 AM, Jacob Bellamy <toarms at gmail.com> wrote:

> I thought fragment identifiers were handled purely by the browser? After a
> url is supplied by the malicious party i would not expect the fragment to
> be visible to either the idp or legitimate rp.
> On Dec 31, 2013 10:36 AM, "John Bradley" <ve7jtb at ve7jtb.com> wrote:
>
>> A IdP adding response parameters to the fragment portion of a redirect
>> URI would be a bug in the IdP as they would never be received by a
>> legitimate RP.
>>
>> That is valid in connect for implicit clients but not in OpenID 2.
>>
>> In OpenID 2 the claimed identifier can have a fragment to distinguish
>> identifier re-use.
>>
>> The solution to open redirectors in openID 2 was RP discovery.  Though
>> most IDP resist it because it makes testing harder and breaks RP that don't
>> publish a XRDS.
>>
>> The compromise many use is that if the RP's XRDS is discovered it must
>> match the redirect URI, otherwise if it is not found anything in the realm
>> works.
>>
>> This is better than nothing but is still susceptible to denial of service
>> attacks to prevent the IdP from retrieving the XRDS.
>>
>> Connect requires the RP/Client to explicitly register there redirect_uri
>> so is much tighter on this.
>>
>> John B.
>>
>>
>> On Dec 30, 2013, at 5:21 PM, Andrew Arnott <andrewarnott at gmail.com>
>> wrote:
>>
>>  It seems the OP is buggy if it adds OpenID parameters to the fragment
>> of a return_to.
>>
>> Sent from my Windows Phone
>>  ------------------------------
>> From: Jacob Bellamy <toarms at gmail.com>
>> Sent: 12/30/2013 12:08 PM
>> To: Andris Atteka <andris.atteka at gmail.com>
>> Cc: openid-security at lists.openid.net
>> Subject: Re: [security] OpenID identity leaks
>>
>> 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<http://2fspecs.openid.net/>
>>>>>> %2Fauth%2F2.0%2Fidentifier_select&openid.
>>>>>> mode=checkid_setup&openid.ns=http%3A%2F%2Fspecs.openid.net<http://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<http://2fspecs.openid.net/>
>>>>>> %2Fextensions%2Fui%2F1.0&openid.realm=https%3A%2F%2Fwww.google.com<http://2fwww.google.com/>
>>>>>> %2F&openid.return_to=https%3A%2F%2Fwww.google.com<http://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
>>>
>>> _______________________________________________
>> 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/20140102/468a23e2/attachment.html>