I suggest we refactor it so that /Security is a general discussion of how security is evaluated and triaged for OpenID, and that /SecurityIssues be where all issues are listed, and that sub-pages to /SecurityIssues actually explain individual issues. -- 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 11:03 AM, Breno de Medeiros <[email protected]>wrote: > Hmmm... we need to consolidate these locations ... Suggestions? > > On Mon, Nov 16, 2009 at 11:00 AM, Andrew Arnott <[email protected]> > wrote: > > 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 > > -- > > 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) > >> > > > > > > > > -- > --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
