[security] Danger of Content-Location HTTP response header

[Andrew Arnott]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20091104/eb1e491b/attachment.htm>