I'll do that. Thanks.<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>
<br><br><div class="gmail_quote">On Mon, Nov 16, 2009 at 10:06 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com">breno@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Andrew,<br>
<br>
This is a sufficiently significant risk that should be documented in<br>
the security wiki. I encourage you to do so.<br>
<div><div></div><div class="h5"><br>
On Sat, Nov 14, 2009 at 7:21 PM, Andrew Arnott <<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>> wrote:<br>
> That's right, John.<br>
> For a vulnerable RP, an attacker could set up any URL to impersonate any<br>
> other user at the RP simply by logging into the RP with his own URL, after<br>
> configuring it to send back the Content-Location header with the victim's<br>
> claimed_id as its value.<br>
> I've confirmed that the extremeswankopenid library is vulnerable to this<br>
> attack, and have contacted the author already.<br>
> Regarding your question about how this is different than delegating your<br>
> identifier to a victim's OpenID... I'm not familiar with such an approach,<br>
> or how that would be exploited.<br>
> --<br>
> Andrew Arnott<br>
> "I [may] not agree with what you have to say, but I'll defend to the death<br>
> your right to say it." - S. G. Tallentyre<br>
><br>
><br>
> On Sat, Nov 14, 2009 at 10:50 AM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:<br>
>><br>
>> This is a attack on discovery.<br>
>> If the RP performs discovery on URL A the owner of URL A can return a XRDS<br>
>> with a content-Location header for URL B. The RP now believes that whatever<br>
>> OP endpoint is in the XRDS is authoritative for URL B without having<br>
>> retrieved the actual XRDS for it, only the one for URL A claiming to be B.<br>
>> The problem is that .Net "helps" the application by making it think a<br>
>> redirect has taken place when it hasn't.<br>
>> There are lots of times when this works just fine however the claimed_id<br>
>> is tied to the product of the second normalization so is vulnerable to this<br>
>> sort of fake redirect.<br>
>> Andrew can provide more of the details.<br>
>> John B.<br>
>> On 2009-11-14, at 2:24 PM, Allen Tom wrote:<br>
>><br>
>> Hi Andrew,<br>
>><br>
>> Would an attacker be able to exploit this issue by returning the<br>
>> Content-Location HTTP response header for an URL that he owns, making his<br>
>> URL equivalent to a victim's OpenID? How is this different from having the<br>
>> attacker delegating his URL to the victim's OpenID?<br>
>><br>
>> Can you outline a scenario where the Content-Location HTTP header is<br>
>> exploited?<br>
>><br>
>> Thanks<br>
>> Allen<br>
>><br>
>><br>
>><br>
>> Arnott wrote:<br>
>><br>
>> Just a heads up from something I recently became aware of that impacted<br>
>> older versions of dotnetopenid.<br>
>> The HTTP protocol defines a Content-Location HTTP response header that<br>
>> allows the web server to suggest to the client that another URL would be<br>
>> equivalent to the one that client actually pulled from. It is not a<br>
>> redirect, but merely a suggestion that two URLs are equivalent. For the<br>
>> purposes of OpenID claimed identifier discovery, it is imperative that an<br>
>> OpenID RP ignore this header, lest a web server upon which discovery was<br>
>> performed can spoof an arbitrary claimed_id's identity by fooling the RP<br>
>> into thinking it discovered an identifier that in fact it did not.<br>
>> In particular, .NET's "helpful" HTTP stack automatically reads this header<br>
>> and reports it to the client as if it was in fact that actual URL that was<br>
>> pulled from even though it wasn't. Since .NET follows redirects<br>
>> automatically by default, a legitimate redirect and this Content-Location<br>
>> header are indiscernable, which is really bad. This is fixed in the<br>
>> dotnetopenid and dotnetopenauth libraries.<br>
>> Other RP library/site authors should verify that the HTTP stack they are<br>
>> using ignore this header, or workaround the issue.<br>
>> I'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<br>
>> whether they are vulnerable. Please take a moment to find out, and fix it<br>
>> ASAP if you are.<br>
>> <a href="http://test-id.org/RP/IgnoresContentLocationHeader.aspx" target="_blank">http://test-id.org/RP/IgnoresContentLocationHeader.aspx</a><br>
>> --<br>
>> Andrew Arnott<br>
>> "I [may] not agree with what you have to say, but I'll defend to the death<br>
>> your right to say it." - S. G. Tallentyre<br>
>><br>
>> ________________________________<br>
>> _______________________________________________<br>
>> security mailing list<br>
>> <a href="mailto:security@lists.openid.net">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>
>><br>
>> _______________________________________________<br>
>> security mailing list<br>
>> <a href="mailto:security@lists.openid.net">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>
><br>
><br>
> _______________________________________________<br>
> security mailing list<br>
> <a href="mailto:security@lists.openid.net">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>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
--Breno<br>
<br>
+1 (650) 214-1007 desk<br>
+1 (408) 212-0135 (Grand Central)<br>
MTV-41-3 : 383-A<br>
PST (GMT-8) / PDT(GMT-7)<br>
</font></blockquote></div><br>