[security] Danger of Content-Location HTTP response header

Mon Nov 16 19:11:06 UTC 2009

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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20091116/6ebbda68/attachment-0001.htm>