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
