Hi Michal, > After some initial and very frightening missteps, a bunch of features > (e.g., CORS, web sockets, navigation timing, etc) were tweaked so that > they have a near-zero effect on the security properties of existing > websites, ... I think you are correct that "they have a near-zero effect on the security properties of existing website." But some additions make it hell on secure applications and an organization's systems as a whole (personally, I don't care about the website).
WebSockets are a concern to me. An attacker almost always wants to egress data (otherwise, what's the point?), so WebSockets are an addition to the attacker's war chest. In addition, WebSockets make it really convenient to setup reverse proxies (emphasize convenient). In the past, we were able to setup firewall rules to block IPs/Ports. More extensible firewalls extended the concept to Programs/Ports. That begs the question, how do we block based on JavaScript/Ports? Under this scenario, we can only give coarse grained permission for Firefox (et al), and not differentiate between the host program and foreign script code. To make matters worse, in mobile the firewall is a disjoint component. So the program executes on a device while the firewall exists at a server (part of a secure browser solution). How is the context passed remotely? How is a remote firewall going to cope with this? Jeff On Tue, Dec 4, 2012 at 4:35 PM, Michal Zalewski <lcam...@coredump.cx> wrote: > Most of the complaints about "new HTML5 attacks" are knee-jerk, or > just use this term for no particular reason. For example, if the new > semantics open up obvious security vulnerabilities in your HTML > sanitizer, it's probably completely pwnable anyway. > > After some initial and very frightening missteps, a bunch of features > (e.g., CORS, web sockets, navigation timing, etc) were tweaked so that > they have a near-zero effect on the security properties of existing > websites, or offer robust benefits (postMessage, JSON.parse, etc). > There is also a bunch of security features that probably won't offer > the promised benefits (e.g., CSP and sandboxed frames), but they also > don't make a huge difference. > > There is a number of serious problems with the web, but for most part, > they have very little to do with HTML5 per se; if the new features > make them worse, it's only incrementally so. It's a shame that nobody > is trying to really tackle them, but "somebody ought to do something" > is always a pretty weak complaint, so... =) > > /mz _______________________________________________ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
