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 <http://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
[email protected]
http://lists.openid.net/mailman/listinfo/openid-security
_______________________________________________
security mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-security
