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
