[security] Danger of Content-Location HTTP response header

[Breno de Medeiros]

Andrew,

This is a sufficiently significant risk that should be documented in
the security wiki. I encourage you to do so.

On Sat, Nov 14, 2009 at 7:21 PM, Andrew Arnott <andrewarnott at gmail.com> wrote:
> That's right, John.
> For a vulnerable RP, an attacker could set up any 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's
> claimed_id as its value.
> I've confirmed that the extremeswankopenid library is vulnerable to this
> attack, and have contacted the author already.
> Regarding your question about how this is different than delegating your
> identifier to a victim's OpenID... I'm not familiar with such an approach,
> or how that would be exploited.
> --
> Andrew Arnott
> "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
>
>
> On Sat, Nov 14, 2009 at 10:50 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>
>> This is a attack on discovery.
>> 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.
>> The problem is that .Net "helps" the application by making it think a
>> redirect has taken place when it hasn't.
>> 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.
>> Andrew can provide more of the details.
>> John B.
>> On 2009-11-14, at 2:24 PM, Allen Tom wrote:
>>
>> Hi Andrew,
>>
>> 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?
>>
>> Can you outline a scenario where the Content-Location HTTP header is
>> exploited?
>>
>> Thanks
>> Allen
>>
>>
>>
>> Arnott wrote:
>>
>> Just a heads up from something I recently became aware of that impacted
>> older versions of dotnetopenid.
>> 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 not 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 ignore 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.
>> 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.
>> Other RP library/site authors should verify that the HTTP stack they are
>> using ignore this header, or workaround the issue.
>> I've set up a test on test-id.org 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.
>> http://test-id.org/RP/IgnoresContentLocationHeader.aspx
>> --
>> Andrew Arnott
>> "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
>>
>> ________________________________
>> _______________________________________________
>> security mailing list
>> security at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-security
>>
>>
>> _______________________________________________
>> security mailing list
>> security at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-security
>>
>
>
> _______________________________________________
> security mailing list
> security at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-security
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)