Interesting. Seems like this proposal could negate most of my organisations security.
This is what I think was meant by King's response:
In response King quipped, "It’s not the super dodgy, poorly maintained native software that I’m worried about. It’s the super dodgy, poorly maintained server software that is now one XSS away from hostile socket connections."
Right now, my organisation has 10's of millions of dollars in firewall appliances, gateways, multi-tier application infrastructure (which is another 10's of millions worth of developer time to create all these multi-tier applications) not to mention a couple-dozen staff who manage and operate and secure that infrastructure.
The multi-tier applications are set up such that there is no direct access to databases to the internet, thus no SQL-injection-type attacks can be made 'raw' from the internet. First stop for outside communications is hitting web applications inside the gateway environment. These don't have any access to the database, that still lies several firewalls away. These apps use various application to application protocols (corba, webservices, message passing/queing) to do fixed-function communications deeper into the application environment. These deeper components sit several firewalls deeper and can only accept those fixed-function and limited protocol communications (i.e. no ssh is allowed in) from the application servers in the gateway. These backend app components also can only perform fixed-functions calls back to the database. Therefore to be able to do arbitary SQL communications with our databases, you'd have to:
1) penetrate several layers of firewalls to gain control over a server in the gateway (since the apps running on it can't do arbitrary calls to their backend, you can't do that by just taking over the apps on the box). Youd have to gain shell access to the box.
2) once you have shell access, you'd have to do an escalation of privilege attack and bypass whitelisting to be able to install software on the box to allow further chaining deeper into the network.
3) rinse and repeat seps 1 and 2 possibly several more times (won't detail any further), that is gain shell access behind more firewalls and escalation-of-privilege to bypass whitelisting and install software to do more chaining.
4) do your attacks against the database.
Sure, our organisations security is penetrable, but it would require a custom attack and (hopefully!) hundreds of man-hours of work to do all the chaining, which gives plenty of opportunities and most importantly time for the security staff to notice something is going on and intervene manually to stop it. It'd be like someone breaking into a bank vault but taking 100 hours to do it, thus getting caught when people turn up for work the next day and notice the crooks attacking the vault. Each organisation attacked would require its own custom attack and dozens or hundreds of hours of work.
Sure, this could be mitigated, desktop firewall rules that only allow the browser to communicate with the proxy server, not allowed to hoik off to random internal destinations. Zone off al the PCs into their own zone so they can't access anything else on the network, but then how to you get to your shared drives? Perform legitimate access to the database? I can think of defenses, but most of them would cause lots of pain to the end-users, e.g. not being able to access the internet at all on your desktop PC, having to remote desktop to another server/PC that is allowed browser access, and so on. But I see massive additional costs to organisations in more security work and lost productivity due to having to 'double-handle' internet access. For example, I access the internet everyday, I am a system administrator, so I'm always doing internet searches on how to resolve issues, looking up info on patches, or looking up documentation, etc.
Yeah, I'm on King's side - if I've interpreted the quoted statement correctly - on this.