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 <http://wiki.openid.net/SecurityIssues> -- 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 <[email protected]>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 <[email protected]>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 <[email protected]> >> 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 <[email protected]> >> 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 >> >> [email protected] >> >> http://lists.openid.net/mailman/listinfo/openid-security >> >> >> >> >> >> _______________________________________________ >> >> 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 >> > >> > >> >> >> >> -- >> --Breno >> >> +1 (650) 214-1007 desk >> +1 (408) 212-0135 (Grand Central) >> MTV-41-3 : 383-A >> PST (GMT-8) / PDT(GMT-7) >> > >
_______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
