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
