[security] OpenID identity leaks
Jacob Bellamy
toarms at gmail.com
Mon Dec 30 22:59:59 UTC 2013
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/20131231/d37878d6/attachment.html>
More information about the security
mailing list