That&#39;s right, John.<div><br></div><div>For a vulnerable RP, an attacker could set up <i>any</i> URL to impersonate any other user at the RP simply by logging into the RP with his own URL, after configuring it to send back the Content-Location header with the victim&#39;s claimed_id as its value.  </div>

<div><br></div><div>I&#39;ve confirmed that the extremeswankopenid library is vulnerable to this attack, and have contacted the author already.</div><div><br></div><div>Regarding your question about how this is different than delegating your identifier to a victim&#39;s OpenID... I&#39;m not familiar with such an approach, or how that would be exploited.</div>

<div><br></div><div>--<br>Andrew Arnott<br>&quot;I [may] not agree with what you have to say, but I&#39;ll defend to the death your right to say it.&quot; - S. G. Tallentyre<br>
<br><br><div class="gmail_quote">On Sat, Nov 14, 2009 at 10:50 AM, John Bradley <span dir="ltr">&lt;<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div style="word-wrap:break-word">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 &quot;helps&quot; the application by making it think a redirect has taken place when it hasn&#39;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.<div><div></div><div class="h5"><br><div><div>On 2009-11-14, at 2:24 PM, Allen Tom wrote:</div><br><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&#39;s OpenID? How is this different from
having the attacker delegating his URL to the victim&#39;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 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&#39;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&#39;s &quot;helpful&quot; 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&#39;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&#39;ve set up a test on <a href="http://test-id.org/" target="_blank">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 href="http://test-id.org/RP/IgnoresContentLocationHeader.aspx" target="_blank">http://test-id.org/RP/IgnoresContentLocationHeader.aspx</a></div>
  <div><br clear="all">
--<br>
Andrew Arnott<br>
&quot;I [may] not agree with what you have to say, but I&#39;ll defend to the
death your right to say it.&quot; - S. G. Tallentyre<br>
  </div>
  <pre><hr size="4" width="90%">
_______________________________________________
security mailing list
<a href="mailto:security@lists.openid.net" target="_blank">security@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-security" target="_blank">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" 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></div></div></blockquote></div><br></div>