I suggest we refactor it so that /Security is a general discussion of how security is evaluated and triaged for OpenID, and that /SecurityIssues be where all issues are listed, and that sub-pages to /SecurityIssues actually explain individual issues.<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 11:03 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;">
Hmmm... we need to consolidate these locations ... Suggestions?<br>
<div><div></div><div class="h5"><br>
On Mon, Nov 16, 2009 at 11:00 AM, Andrew Arnott <<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>> wrote:<br>
> I've added it to <a href="http://wiki.openid.net/Reported_Security_Issues" target="_blank">http://wiki.openid.net/Reported_Security_Issues</a>,<br>
> Although between these URLs, and their content, it was difficult to figure<br>
> out exactly where was most appropriate. So let me know if I guessed wrong.<br>
> <a href="http://wiki.openid.net/Security" target="_blank">http://wiki.openid.net/Security</a><br>
> <a href="http://wiki.openid.net/SecurityIssues" target="_blank">http://wiki.openid.net/SecurityIssues</a><br>
> <a href="http://wiki.openid.net/Reported_Security_Issues" target="_blank">http://wiki.openid.net/Reported_Security_Issues</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>
> On Mon, Nov 16, 2009 at 10:42 AM, Andrew Arnott <<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>><br>
> wrote:<br>
>><br>
>> I'll do that. Thanks.<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 Mon, Nov 16, 2009 at 10:06 AM, Breno de Medeiros <<a href="mailto:breno@google.com">breno@google.com</a>><br>
>> wrote:<br>
>>><br>
>>> 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>
>>><br>
>>> On Sat, Nov 14, 2009 at 7:21 PM, Andrew Arnott <<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>><br>
>>> wrote:<br>
>>> > That's right, John.<br>
>>> > For a vulnerable RP, an attacker could set up any URL to impersonate<br>
>>> > any<br>
>>> > other user at the RP simply by logging into the RP with his own URL,<br>
>>> > after<br>
>>> > configuring it to send back the Content-Location header with the<br>
>>> > victim's<br>
>>> > claimed_id as its value.<br>
>>> > I've confirmed that the extremeswankopenid library is vulnerable to<br>
>>> > this<br>
>>> > attack, and have contacted the author already.<br>
>>> > Regarding your question about how this is different than delegating<br>
>>> > your<br>
>>> > identifier to a victim's OpenID... I'm not familiar with such an<br>
>>> > 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<br>
>>> > 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>><br>
>>> > 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<br>
>>> >> XRDS<br>
>>> >> with a content-Location header for URL B. The RP now believes that<br>
>>> >> 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<br>
>>> >> 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<br>
>>> >> claimed_id<br>
>>> >> is tied to the product of the second normalization so is vulnerable to<br>
>>> >> 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<br>
>>> >> his<br>
>>> >> URL equivalent to a victim's OpenID? How is this different from having<br>
>>> >> 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<br>
>>> >> 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<br>
>>> >> 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<br>
>>> >> the<br>
>>> >> purposes of OpenID claimed identifier discovery, it is imperative that<br>
>>> >> an<br>
>>> >> OpenID RP ignore this header, lest a web server upon which discovery<br>
>>> >> was<br>
>>> >> performed can spoof an arbitrary claimed_id's identity by fooling the<br>
>>> >> 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<br>
>>> >> header<br>
>>> >> and reports it to the client as if it was in fact that actual URL that<br>
>>> >> was<br>
>>> >> pulled from even though it wasn't. Since .NET follows redirects<br>
>>> >> automatically by default, a legitimate redirect and this<br>
>>> >> 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<br>
>>> >> 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<br>
>>> >> 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<br>
>>> >> 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>
>>> --<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>
>><br>
><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<div><div></div><div class="h5">--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>
</div></div></blockquote></div><br>