That sounds pretty good. /Security should be the landing page.
/Security-Issues (I tend to prefer naming with spaces or hyphens for SEO/readability) should be for the list of known and fixed security issues. /Security-Report-[descriptive-shortname] could be used for the details of an individual report. Are there good templates for such reports on the web? I can import one to the wiki so that it'd be available in the dropdown list of templates. Chris On Mon, Nov 16, 2009 at 11:11 AM, Andrew Arnott <[email protected]>wrote: > 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 > > -- Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] shareable [X] ask first [ ] private
_______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
