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 <[email protected]> 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" <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> Sent: 12/30/2013 12:08 PM >> To: Andris Atteka <[email protected]> >> Cc: [email protected] >> 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" <[email protected]> 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 <[email protected]>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 < >>>>> [email protected] >>>>> <mailto:[email protected]>> 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 >>>>>> [email protected] <mailto:[email protected]> >>>>>> http://lists.openid.net/mailman/listinfo/openid-security >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> security mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> >>>>> http://lists.openid.net/mailman/listinfo/openid-security >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> security mailing list >>>>> [email protected] >>>>> http://lists.openid.net/mailman/listinfo/openid-security >>>>> >>>>> >>> >>> _______________________________________________ >>> security mailing list >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-security >>> >>> _______________________________________________ >> security mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-security >> >> >>
_______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
