Browser Session Virtualization
I hope this doesn’t come across as a back-handed complement, but I had a better time at SOURCE than I expected. It was a great first year conference, and I really liked the information feel compared to the larger shows. I know they plan on growing it, and someday I’ll wax nostalgic about this first year.
There’s something I’ve been talking about in presentations lately that I haven’t had a chance to blog about yet. I was having a conversation with Robert Hansen of SecTheory (Rsnake to you researchers) and it really helped me refine the concept a bit.
The basic premise is that we need to assume that any browser that connects to our applications is completely compromised. Attacks like cross-site request forgery are just too difficult for the average browser/application to defend against. A big part of the problem is that the browser is a multi-session tool. Unlike most of our client/server desktop applications, the browser needs the ability to mix content from multiple sources, often in a single window. It’s how the whole darn Internet works.
What we ideally need is a way to completely isolate our content in the browser. One way to do this is session virtualization, pioneered by GreenBorder, who was later acquired by Google (the GreenBorder site is just in support mode now). When a user connects to our site, we push down some code to create a virtual environment in the browser that we strictly control. We wall off that session, which could just be an isolated iFrame in a page, so that it only accesses content we send it. Basically, we break the normal browser model and hijack what we need. This would, for example, help stop CSRF since other browser elements won’t be able to trigger a connection to our application. Done right, it limits man in the middle attacks, even if the user authorizes a bad digital certificate.
To work properly, this needs to be tied to a gateway that controls the session. While we could do it from the web/app server itself, I suspect we’ll see this as a web application firewall feature, just as we see similar features from SSL-VPNs. I think isolated WAFs have a very limited lifespan, but this is exactly the kind of feature that will extend their value. Better yet, we can tie this in to our Application and Database Monitoring and Protection to build a browser-to-database protected path. We can completely track a transaction or piece of content from the database server to the browser and back.
We could even use this to isolate out potentially “bad” content in an in-browser sandbox. For example, it could be a way to enable all those social networking widgets in a more controlled way but locking in potentially bad content instead of known good.
Will this protect us from keystroke sniffers or a completely compromised host? Nope, but it will definitely help with a large number of our current browser security issues. If we combine it with full ADMP and additional methods like transaction authentication, I think we can regain a bit of control of the web application security mess.
Technorati Tags: Application and Database Monitoring and Protection, Application security, Browser, Data security, Information-centric security, ADMP, Session Virtualization, SSL-VPN
Mike Rothman Mar 17
Isn’t doing things within iFrames behind the scenes one of the key techniques of the bad guys? How is this different than what they do to “break the normal browser model and hijack what we need.” More importantly, how do the visitors know the difference?
I routinely suggest folks use NoScript, which presumably would break this kind of application model. I guess I could white list it, since your site is presumably trusted - but still. It seems like fighting fire with fire. Though I’m not sure what a better answer is…
rmogull Mar 17
Sort of.
Instead of an iFrame, we take complete control of the session and virtualize it to prevent any cross-domain issues. The iframe is a technique they use to hide the origin of content or push things into a session that shouldn’t be there. We’re using it as an isolation technique.
Besides, the iframe model seems to work for them, no reason it can’t work for us. (iFrames will probably be part of what I’m talking about, but only part).
Hansen/Rsnake brought up a similar problem- with my model we’re training users to download stuff again. Ideally we could put some of this tech in the browser like root certs, but I figure we’ve lost that battle with users anyway.
ds Mar 18
This sort of virtualization sounds like an enhancement of the idea offered in the NAC world for untrusted browsers (e.g., Sygate On Demand Agent).
It also seems much more palatable than the notion of application specific browsers that I’ve seen some blog about, as that concept seems oxymoronic.
How does this idea compare with something like the application control offered by Verdasys’ Digital Guardian, specifically with sandboxing?
rmogull Mar 18
That’s EXACTLY where the idea comes from, I’m not so prescient as to figure this stuff out on my own.
Verdasys isn’t virtualization or sandboxing, and can’t get to that level in the browser. We’re talking about completely isolating sessions, not just applications. ALso, this model is controlled by the web application, where Verdasys is internal security software.
I’m not a fan of those app specific browsers either.