I guess what I meant was, the vulnerability exists on the proxy. Poisioning the cache requires deliberate (or freakishly inadvertent accidental) steps taken to compromise the proxy. Yes, other clients then using that proxy are I guess potentially compromised but there’s not a whole heck of a lot you can do about that, is there?
Browsers have a responsibility to prevent themselves from being used in an attack, because a browser does something that other connected sockets applications don’t do... i.e. download and execute code from arbitrary sources – web sites. Opera and Firefox et al have to close the hole because if they didn’t, miscreants could contrive a means to have users visit a site that downloads exploit code to be run in the browser. You can clean up your Delphi code (assuming it even needs it) all you like, but if somebody else comes along and compromises a proxy that your application is routing traffic through (whether by choice or dint of circumstance), then you are still screwed. afaict. From: [email protected] [mailto:[email protected]] On Behalf Of John Bird Sent: Monday, 13 December 2010 11:49 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Web Sockets security hole As I understand, a Web Socket connecting via a proxy can be fooled in the case of many proxies to connect to a different site altogether due to a weakness in the UPGRADE protocol which can be exploited by poisoning the DNS cache. The CONNECT protocol (not yet implemented) seems to be OK, and wss (Secure sockets may be ok). It looks like a hole in security for the way many or most proxies are implemented that affects Web Sockets going via them. I am still unsure how major this is and the implications, but as far as Opera and Firefox V4 are concerned they have turned off this protocol in HTML5 until it can be made secure. It looks like a relative of the DNS poisoning cache security hole that had major releases of patches by a wide range of suppliers done urgently about a year ago to fix a basic DNS flaw also involving poisoning the DNS cache to point browsers and HTTP traffic to the wrong IP address. My main questions were: is there much Delphi stuff out there using Web Sockets? and might this vulnerability with proxies something such people might need to take a look at (even if the proxy were not a Delphi product)? (I use diddly squat Indy stuff myself so all of this is at a distance from me – just wanted to pass it on) John From: Jolyon Smith <mailto:[email protected]> Sent: Monday, December 13, 2010 11:20 AM To: 'NZ Borland Developers Group - Delphi List' <mailto:[email protected]> Subject: Re: [DUG] Web Sockets security hole I may be wrong but a quick read of the top link suggests to me that the issues lies specifically in the implementation of various proxies. If that’s the case, any implications for Delphi would be for people implementing proxies using Indy, but NOT for clients or servers themselves. From: [email protected] [mailto:[email protected]] On Behalf Of John Bird Sent: Monday, 13 December 2010 11:08 To: NZ Borland Developers Group - Delphi List Subject: [DUG] Web Sockets security hole Here is a reference I picked up on the Firefox list about a a security hole in Web Sockets – and affects Java, Flash and HTML5. Research done by Adam Barth of Google. http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html http://www.adambarth.com/experimental/websocket.pdf https://bugzilla.mozilla.org/show_bug.cgi?id=616733 As I am not an Indy etc expert I was wondering if anyone wanted to comment if there is any implication for Delphi? John _____ _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
