<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This is a attack on discovery.<div><br></div><div>If the RP performs discovery on URL A the owner of URL A can return a XRDS with a content-Location header for URL B. The RP now believes that whatever OP endpoint is in the XRDS is authoritative for URL B without having retrieved the actual XRDS for it, only the one for URL A claiming to be B.</div><div><br></div><div>The problem is that .Net "helps" the application by making it think a redirect has taken place when it hasn't.</div><div><br></div><div>There are lots of times when this works just fine however the claimed_id is tied to the product of the second normalization so is vulnerable to this sort of fake redirect.</div><div><br></div><div>Andrew can provide more of the details.</div><div><br></div><div>John B.<br><div><div>On 2009-11-14, at 2:24 PM, Allen Tom wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
Hi Andrew,<br>
<br>
Would an attacker be able to exploit this issue by returning the
Content-Location HTTP response header for an URL that he owns, making
his URL equivalent to a victim's OpenID? How is this different from
having the attacker delegating his URL to the victim's OpenID?<br>
<br>
Can you outline a scenario where the Content-Location HTTP header is
exploited?<br>
<br>
Thanks<br>
Allen<br>
<br>
<br>
<br>
Arnott wrote:
<blockquote cite="mid:216e54900911040945p4335be3fqea367a56736925c0@mail.gmail.com" type="cite">Just a heads up from something I recently became aware of
that impacted older versions of dotnetopenid.
<div><br>
</div>
<div>The HTTP protocol defines a Content-Location HTTP response
header that allows the web server to suggest to the client that another
URL would be equivalent to the one that client actually pulled from.
It is<i> not</i> a redirect, but merely a suggestion that two URLs are
equivalent. For the purposes of OpenID claimed identifier discovery,
it is imperative that an OpenID RP <i>ignore</i> this header, lest a
web server upon which discovery was performed can spoof an arbitrary
claimed_id's identity by fooling the RP into thinking it discovered an
identifier that in fact it did not.</div>
<div><br>
</div>
<div>In particular, .NET's "helpful" HTTP stack automatically reads
this header and reports it to the client as if it was in fact that
actual URL that was pulled from even though it wasn't. Since .NET
follows redirects automatically by default, a legitimate redirect and
this Content-Location header are indiscernable, which is really bad.
This is fixed in the dotnetopenid and dotnetopenauth libraries.</div>
<div><br>
</div>
<div>Other RP library/site authors should verify that the HTTP stack
they are using ignore this header, or workaround the issue. </div>
<div><br>
</div>
<div>I've set up a test on <a moz-do-not-send="true" href="http://test-id.org/">test-id.org</a> where an RP can very quickly
assess whether they are vulnerable. Please take a moment to find out,
and fix it ASAP if you are.</div>
<div><a moz-do-not-send="true" href="http://test-id.org/RP/IgnoresContentLocationHeader.aspx">http://test-id.org/RP/IgnoresContentLocationHeader.aspx</a></div>
<div><br clear="all">
--<br>
Andrew Arnott<br>
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - S. G. Tallentyre<br>
</div>
<pre wrap=""><hr size="4" width="90%">
_______________________________________________
security mailing list
<a class="moz-txt-link-abbreviated" href="mailto:security@lists.openid.net">security@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-security">http://lists.openid.net/mailman/listinfo/openid-security</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>security mailing list<br><a href="mailto:security@lists.openid.net">security@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-security<br></blockquote></div><br></div></body></html>