[security] Danger of Content-Location HTTP response header

Mon Nov 16 19:03:49 UTC 2009

Hmmm... we need to consolidate these locations ... Suggestions?

On Mon, Nov 16, 2009 at 11:00 AM, Andrew Arnott <andrewarnott at gmail.com> wrote:
> 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
> --
> 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)
>>
>
>

-- 
--Breno

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