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 >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-security >> > > _______________________________________________ > security mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-security
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
