Paper: "BrowserShield: Vulnerability-Driven Filtering of Dynamic HTML"
BrowserShield: Vulnerability-Driven Filtering of Dynamic HTML
Charles Reis, University of Washington; John Dunagan, Helen J. Wang, and Opher Dubrovsky, Microsoft; Saher Esmeir, Technion
Abstract
Vulnerability-driven filtering of network data can offer a fast and easy-to-deploy alternative or intermediary to software patching, as exemplified in Shield. In this paper, we take Shield's vision to a new domain, inspecting and cleansing not just static content, but also dynamic content. The dynamic content we target is the dynamic HTML in web pages, which have become a popular vector for attacks. The key challenge in filtering dynamic HTML is that it is undecidable to statically determine whether an embedded script will exploit the browser at run-time. We avoid this undecidability problem by rewriting web pages and any embedded scripts into safe equivalents, inserting checks so that the filtering is done at run-time. The rewritten pages contain logic for recursively applying run-time checks to dynamically generated or modified web content, based on known vulnerabilities. We have built and evaluated BrowserShield, a system that performs this dynamic instrumentation of embedded scripts, and that admits policies for customized run-time actions like vulnerability-driven filtering.
posted by Jeff Mogul at 5:29 PM
2 Comments:
How much of the increase in time-to-render is due to the cost of interpreted execution of the client-side library?
If it's a lot, would it make sense to replace this library with built-in modifications to the client's Javascript interpreter? That is, change the browser(s) once so that they can efficiently support BrowserShield (leaving open the possibility of additional interpreted client-side code if new features are needed later).
BrowserShield: Vulnerability-Driven Filtering of Dynamic HTML
Charles Reis, University of Washington; John Dunagan, Helen J. Wang, and Opher Dubrovsky, Microsoft; Saher Esmeir, Technion
Presented by Charles Reis
Web Browsers have vulnerabilities that can be exploited by simply visiting a web page. The traditional line of defence against this treat is through software patching. Unfortunately there is often a long delay between the time a patch is released and its application for reasons such as the need for testing before deployment. This delay opens a dangerous time window where attackers can even use the patch as a blueprint to create exploits.
A previous approach, Shield, aims to provide protection equivalent to patching but with easier deployment and roll-back. Shield allows filtering of malicious static content using vulnerability signatures. BrowserShield's goal is to provide similar protection for dynamic web content by rewriting embedded scripts into safe equivalent on their way to the browser. BrowserShield is decoupled from the browser, providing flexibility in terms of deployment.
BrowserShield consists of a JavaScript library and a logic injector which could be located at the server, firewall or even as a proxy on the client. Both components are configured using flexible policies that can be tailored to address specific vulnerabilities. The injector performs a first translation which modifies the HTML to remove exploits and wraps all embedded scripts to force them to be invoked via the BrowserShield library. The library performs a second translation during page rendering by dynamically rewritting scripts to access the HTML document tree via an interposition layer.
The evaluation shows that combined with anti-virus and HTML filtering, BrowserShield provides patch equivalent protection for all 19 vulnerabilites in IE for which patches were released in 2005.
George Candea from EPFL asked on the guarantees that can be provided that pages will be rendered correctly. The answer is that it's much easier to rollback a policy than an applied browser patch when something goes wrong. The policies are also written at a higher level and do not have to deal with browser internals. A BrowserShield policy only affects pages, not the browser itself. George then asked how to evaluate the policies. Charles answered that the two metrics are how easy it is to write a policy and how to toroughly test policies. The authors believe that as long as policies remain simple than these
Jason Flinn from University of Michigan asked if the scripting was part of the TCB. Charles Reis acquiesced. Brad Chen from Google asked about specific things that the authors would like to see added or removed from JavaScript. Charles Reiss answered that a smaller API would make it easier to achieve complete interposition. Benjamin Reed from Yahoo inquired on how to debug a policy once deployed. Charles Reis answered that it's important to first distinguish if a problem is due to BrowserShield or due to the page or browser. A solution would be to render the page in a unprotected browser running in a virtual machine. Benjamin further asked what should the core dump look like. Charles answered that BrowserShield could be enhanced with a set of debugging policies to generate the appropriate information.
Finally, Diwaker Gupta from UCSD asked how to prevent infinite loops in the script translation. Charles answered that if the script had an infinite loop then its interpretation would fall into an infinite loop but he didn't think that it was possible for a script to force the translation step into an infinite loop.
Post a Comment
<< Home