[security] Danger of Content-Location HTTP response header

Mon Nov 16 21:38:11 UTC 2009

That sounds pretty good.

/Security should be the landing page.

/Security-Issues (I tend to prefer naming with spaces or hyphens for
SEO/readability) should be for the list of known and fixed security issues.

/Security-Report-[descriptive-shortname] could be used for the details of an
individual report.

Are there good templates for such reports on the web? I can import one to
the wiki so that it'd be available in the dropdown list of templates.

Chris

On Mon, Nov 16, 2009 at 11:11 AM, Andrew Arnott <andrewarnott at gmail.com>wrote:

> 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.
>
> --
> 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 11:03 AM, Breno de Medeiros <breno at google.com>wrote:
>
>> 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)
>>
>
>
> _______________________________________________
> security mailing list
> security at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-security
>
>

-- 
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] shareable    [X] ask first   [ ] private
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20091116/01963b90/attachment.htm>