<p>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. </p>
<div class="gmail_quote">On Dec 31, 2013 10:36 AM, "John Bradley" <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">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.<div><br></div><div>That is valid in connect for implicit clients but not in OpenID 2. </div>
<div><br></div><div>In OpenID 2 the claimed identifier can have a fragment to distinguish identifier re-use. </div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>This is better than nothing but is still susceptible to denial of service attacks to prevent the IdP from retrieving the XRDS.</div>
<div><br></div><div>Connect requires the RP/Client to explicitly register there redirect_uri so is much tighter on this.</div><div><br></div><div>John B.</div><div><br></div><div><br></div><div><div><div>On Dec 30, 2013, at 5:21 PM, Andrew Arnott <<a href="mailto:andrewarnott@gmail.com" target="_blank">andrewarnott@gmail.com</a>> wrote:</div>
<br><blockquote type="cite">
<div>
<div>
<div style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif">It seems the OP is buggy if it adds OpenID parameters to the fragment of a return_to.<br><br>Sent from my Windows Phone</div></div>
<div dir="ltr">
<hr>
<span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bold">From: </span><span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif"><a href="mailto:toarms@gmail.com" target="_blank">Jacob Bellamy</a></span><br>
<span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bold">Sent: </span><span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif">12/30/2013 12:08 PM</span><br>
<span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bold">To: </span><span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif"><a href="mailto:andris.atteka@gmail.com" target="_blank">Andris Atteka</a></span><br>
<span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bold">Cc: </span><span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif"><a href="mailto:openid-security@lists.openid.net" target="_blank">openid-security@lists.openid.net</a></span><br>
<span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bold">Subject: </span><span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif">Re: [security] OpenID identity leaks</span><br><br></div></div><p>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?</p>
<p>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. </p>
<div class="gmail_quote">On Dec 31, 2013 3:12 AM, "Andris Atteka" <<a href="mailto:andris.atteka@gmail.com" target="_blank">andris.atteka@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>Hi Johnny,</div><div><br></div><div>yes, mandatory RP discovery would help here, however as you correctly pointed out, it's not widely used.</div><div><br></div><div>I'll try to explain the issue I'm raising more detailed:</div>
<div><br></div><div>Browsers preserve URL fragment across HTTP redirects, e.g.</div><div><a href="https://www.google.com/search?btnI&q=allinurl%3A%2F%2Flva.lv#fragment" target="_blank">https://www.google.com/search?btnI&q=allinurl%3A%2F%2Flva.lv#fragment</a></div>
<div><br></div><div>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.</div>
<div>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.</div><div><br></div><div>I was just wondering why so many OPs allow fragment identifier in return_to (e.g. here's another one - <a href="https://pip.verisignlabs.com/" target="_blank">https://pip.verisignlabs.com/</a>)? Is there some intended functionality?</div>
<div><br></div><div>Regards,</div><div>Andris</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 25, 2013 at 11:52 PM, Johnny Bufu <span dir="ltr"><<a href="mailto:johnny.bufu@gmail.com" target="_blank">johnny.bufu@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
<a href="http://openid.net/specs/openid-authentication-2_0.html#rp_discovery" target="_blank">http://openid.net/specs/<u></u>openid-authentication-2_0.<u></u>html#rp_discovery</a><br>
<br>
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.<br>
<br>
Johnny<div><br>
<br>
On 13-12-21 02:35 AM, Andris Atteka wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
Hi Bart,<br>
<br>
Thanks for your response, however this case is a bit different from what<br>
you are describing.<br>
If you try the link I sent out, you'll notice that identity is leaked<br>
before any user action.<br>
<br>
Regards,<br>
Andris<br>
<br>
<br>
On Sat, Dec 21, 2013 at 12:07 PM, Bart van Delft <<a href="mailto:bartvandelft@yahoo.com" target="_blank">bartvandelft@yahoo.com</a><br></div><div>
<mailto:<a href="mailto:bartvandelft@yahoo.com" target="_blank">bartvandelft@yahoo.com</a><u></u>>> wrote:<br>
<br>
Hi Andris,<br>
<br>
What you suggest sounds a bit like realm spoofing? In that case it<br>
is a known vulnerability of OpenID:<br>
<a href="http://wiki.openid.net/w/page/12995216/OpenID_Phishing_Brainstorm" target="_blank">http://wiki.openid.net/w/page/<u></u>12995216/OpenID_Phishing_<u></u>Brainstorm</a><br>
<br>
Best regards,<br>
<br>
Bart van Delft<br>
<br>
<br>
On 2013-12-21 10:12, Andris Atteka wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
Hi Everyone,<br>
<br>
Google's Security Team suggested to ask this question here.<br>
<br>
Attacker can perform the following steps:<br>
1) Find an open redirect in some major website that leads to<br>
attacker's website (and append fragment identifier to this URL)<br>
2) Craft a URL and set redirect_url to the open redirect<br>
3) Trick the victim into visiting the URL<br>
As the URL belongs to a major website, most likely victim will<br>
accept the RP and his identity will be leaked to attacker's site.<br>
<br>
Here's an example (Google itself has some nice open redirects):<br>
<a href="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" target="_blank">https://www.google.com/<u></u>accounts/o8/ud?openid.claimed_<u></u>id=http%3A%2F%2Fspecs.openid.<u></u>net%2Fauth%2F2.0%2Fidentifier_<u></u>select&openid.ext0.mode=fetch_<u></u>request&openid.ex</a><br>
t0.requ<br>
ired=email&openid.ext0.type.<u></u>email=http%3A%2F%2Faxschema.<u></u>org%2Fcontact%2Femail&openid.<u></u>identity=http%3A%2F%<a href="http://2fspecs.openid.net/" target="_blank">2Fspecs.<u></u>openid.net</a>%2Fauth%2F2.0%<u></u>2Fidentifier_select&openid.<u></u>mode=checkid_setup&openid.ns=<u></u>http%3A%2F%<a href="http://2fspecs.openid.net/" target="_blank">2Fspecs.openid.net</a>%<u></u>2Fauth%2F2.0&openid.ns.ext0=<u></u>http%3A%2F%<a href="http://2Fopenid.net" target="_blank">2Fopenid.net</a>%2Fsrv%<u></u>2Fax%2F1.0&openid.ns.ui=http%<u></u>3A%2F%<a href="http://2fspecs.openid.net/" target="_blank">2Fspecs.openid.net</a>%<u></u>2Fextensions%2Fui%2F1.0&<u></u>openid.realm=https%3A%2F%<a href="http://2fwww.google.com/" target="_blank">2Fwww<u></u>.google.com</a>%2F&openid.return_<u></u>to=https%3A%2F%<a href="http://2fwww.google.com/" target="_blank">2Fwww.google.<u></u>com</a>%2Fsearch%3FbtnI%26q%<u></u>3Dallinurl%253A%252F%252Flva.<u></u>lv%23aaa&openid.ui.icon=true&<u></u>openid.ui.lang=en-US&openid.<u></u>ui.mode=popup&third_party_<u></u>login=false<br>
</div>
<<a href="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" target="_blank">https://www.google.com/<u></u>accounts/o8/ud?openid.claimed_<u></u>id=http%3A%2F%2Fspecs.openid.<u></u>net%2Fauth%2F2.0%2Fidentifier_<u></u>select&openid.ext0.mode=fetch_<u></u>request&openid.ext0.required=<u></u>email&openid.ext0.type.email=<u></u>http%3A%2F%2Faxschema.org%<u></u>2Fcontact%2Femail&openid.<u></u>identity=http%3A%2F%2Fspecs.<u></u>openid.net%2Fauth%2F2.0%<u></u>2Fidentifier_select&openid.<u></u>mode=checkid_setup&openid.ns=<u></u>http%3A%2F%2Fspecs.openid.net%<u></u>2Fauth%2F2.0&openid.ns.ext0=<u></u>http%3A%2F%2Fopenid.net%2Fsrv%<u></u>2Fax%2F1.0&openid.ns.ui=http%<u></u>3A%2F%2Fspecs.openid.net%<u></u>2Fextensions%2Fui%2F1.0&<u></u>openid.realm=https%3A%2F%<u></u>2Fwww.google.com%2F&openid.<u></u>return_to=https%3A%2F%2Fwww.<u></u>google.com%2Fsearch%3FbtnI%<u></u>26q%3Dallinurl%253A%252F%<u></u>252Flva.lv%23aaa&openid.ui.<u></u>icon=true&openid.ui.lang=en-<u></u>US&openid.ui.mode=popup&third_<u></u>party_login=false</a>><div>
<br>
<br>
This can even be extended so that user doesn't have to accept RP.<br>
For this attacker would have to find an open redirect that shares<br>
domain with some valid OpenID consumer (some major sites actually<br>
do this). In this case user wouldn't even notice the identity leak.<br>
<br>
Is this only a bug in Google's OpenID implementation or a bug in<br>
the OpenID spec itself?<br>
<br>
I do see the OpenID spec talking about normalization of<br>
identifiers (including removal of fragment and fragment<br>
identifier). Does the same apply to redirect_url? If not, would it<br>
be reasonable to include this in the spec?<br>
<br>
Regards,<br>
Andris Atteka<br></div>
<a href="http://andrisatteka.blogspot.com/" target="_blank">andrisatteka.blogspot.com</a> <<a href="http://andrisatteka.blogspot.com/" target="_blank">http://andrisatteka.blogspot.<u></u>com</a>><br>
<br>
<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
security mailing list<br>
<a href="mailto:security@lists.openid.net" target="_blank">security@lists.openid.net</a> <mailto:<a href="mailto:security@lists.openid.net" target="_blank">security@lists.openid.<u></u>net</a>><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-security" target="_blank">http://lists.openid.net/<u></u>mailman/listinfo/openid-<u></u>security</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
security mailing list<br>
<a href="mailto:security@lists.openid.net" target="_blank">security@lists.openid.net</a> <mailto:<a href="mailto:security@lists.openid.net" target="_blank">security@lists.openid.<u></u>net</a>><div><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-security" target="_blank">http://lists.openid.net/<u></u>mailman/listinfo/openid-<u></u>security</a><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
security mailing list<br>
<a href="mailto:security@lists.openid.net" target="_blank">security@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-security" target="_blank">http://lists.openid.net/<u></u>mailman/listinfo/openid-<u></u>security</a><br>
<br>
</div></blockquote>
</blockquote></div><br></div>
<br>_______________________________________________<br>
security mailing list<br>
<a href="mailto:security@lists.openid.net" target="_blank">security@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-security" target="_blank">http://lists.openid.net/mailman/listinfo/openid-security</a><br>
<br></blockquote></div>
_______________________________________________<br>security mailing list<br><a href="mailto:security@lists.openid.net" target="_blank">security@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-security" target="_blank">http://lists.openid.net/mailman/listinfo/openid-security</a><br>
</blockquote></div><br></div></div></blockquote></div>