[security] Danger of Content-Location HTTP response header

[Andrew Arnott]

I've added it to http://wiki.openid.net/Reported_Security_Issues,

Although between these URLs, and their content, it was difficult to figure
out exactly where was most appropriate.  So let me know if I guessed wrong.

http://wiki.openid.net/Security
http://wiki.openid.net/SecurityIssues
http://wiki.openid.net/Reported_Security_Issues
 <http://wiki.openid.net/SecurityIssues>
--
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 Mon, Nov 16, 2009 at 10:42 AM, Andrew Arnott <andrewarnott at gmail.com>wrote:

> I'll do that.  Thanks.
>
> --
> 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 Mon, Nov 16, 2009 at 10:06 AM, Breno de Medeiros <breno at google.com>wrote:
>
>> 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)
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20091116/4c430ae6/attachment-0001.htm>