Put new issues at the bottom of this page

Identity spoofing via the Content-Location HTTP response header

Summary

This issue impacts OpenID 1.1 and 2.0 relying parties.

An attacker can set up an OpenID Claimed Identifier that with the discovery response can send an HTTP header that may trick the relying party into believe it is another user's claimed identifier, allowing the attacker to completely spoof a victim's identity at the RP.

Reporter

Andrew Arnott (http://blog.nerdbank.net/)

Description of Issue

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. An OpenID relying party that considers that header to be authoritative of the other URL is vulnerable to this identity spoofing attack. While an OpenID RP library or web site may ignore this header, the HTTP stack used by that library or web site may automatically read that header and report that URL as the final responding URL, thus thwarting the security measures taken during OpenID discovery and allowing the spoofing attack.

In particular, .NET's HttpWebResponse.ResponseUri 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. This property is usually accessed in order to get the URL after all redirects per the OpenID spec, but this is the wrong property to use.  Instead, the HttpWebRequest.Address property should be used, which is the last URL after all redirects that actually responded to the HTTP request.

For the purposes of OpenID claimed identifier discovery, it is imperative that an OpenID RP ignore this header, taking measures to ensure that any underlying HTTP library also ignores the 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.

RP library/site authors should verify that the HTTP stack they are using ignore this header, or workaround the issue. There are (or were at time of initial investigation) multiple RP libraries that are actually vulnerable to this attack.

Steps to Reproduce

A simple script of the repro has been written to make it very simple for RPs to test for vulnerability to this issue.

1. Navigate to http://test-id.org/RP/IgnoresContentLocationHeader.aspx
2. Follow the instructions on that test.

<Name of Issue>

Summary

<version of the OpenID specification against which the issue is reported> <summary of issue>

Reporter

<your name and OpenID>

Description of Issue

<longer text explaining the issue, and what benefits the attacker gains with the attack>

Steps to Reproduce

1. <step 1>
2. <step 2>...