Presentation on theme: "BrowserShield: Vulnerability- Driven Filtering of Dynamic HTML CHARLES REIS University of Washington JOHN DUNAGAN, HELEN J. WANG, and OPHER DUBROVSKY."— Presentation transcript:
BrowserShield: Vulnerability- Driven Filtering of Dynamic HTML CHARLES REIS University of Washington JOHN DUNAGAN, HELEN J. WANG, and OPHER DUBROVSKY Microsoft and SAHER ESMEIR Technion Presenter:Ravindar R Yenugu
Outline Introduction to Topic Overview of Shield Model Limits of Shield Model Overview of BrowserShield Implementation Results Conclusions
WEB BASED ATTACKS Web Based Attacks Web browser exploits are common examples: Buffer overflows, ActiveX flaws, etc. - -- 19 critical vulnerabilities, 8 patches in 2005 - --16 critical vulnerabilities, 7 updates in 2005
Shields: End-host Vulnerability-Driven Network Filters Goal: Protect the time window between vulnerability disclosure and patch application. Approach: Characterize the vulnerability instead of its exploits and use the vulnerability signature for end-host fire walling. Advantages of Shield: Protection as good as patches (resilient to attack variations), unlike exploit-driven firewalls Easier to test and deploy, more reliable than patches
Drawbacks of shield model Shield works for static HTML Script code can hide exploits -finding exploits is undecidable Can’t know deterministically until runtime
Challenges The key challenge in filtering dynamic HTML is that it is undecidable to statically determine whether an embedded script will exploit the browser at runtime. 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 runtime.
Deployment of BrowserShield They have implemented a prototype of the BrowserShield system, in which the rewriting logic is injected into a Web page at an enterprise firewall and executed by the browser at rendering time. They chose the firewall deployment scenario because it offers the greatest manageability benefit, as BrowserShield updates can be centralized at the firewall, immediately protecting all client machines in the organization without any BrowserShield–related installation at either clients or web servers.
Characteristics of Browser shield Complete interposition: All script access to the HTML document tree must be mediated by the BrowserShield framework. Tamper-proof: Web pages must not be able to modify or tamper with the BrowserShield framework in unintended ways. Transparency: Apart from timing considerations and reasonable increases in resource usage, web pages should not be able to detect any changes in behavior due to the BrowserShield framework. The sole exception is for policy enforcement (e.g., the behavior of a page containing an exploit is visibly modified). Flexible policies: We desire the BrowserShield framework to have a good separation between mechanism and policy, to make the system flexible for many applications.
Complete Interposition To provide complete interposition, BrowserShield must mediate all possible accesses and manipulations allowed by the Document Object Model (DOM) over the HTML document trees (including script elements). we achieve this using script rewriting to interpose on function calls, object method calls, object property accesses, object creation, and control constructs. These interposition points are sufficient to mediate script access to the DOM. We summarize our rewriting rules in following table.
Tamper proof enforcement Preventing scripts from tampering with BrowserShield is challenging because BrowserShield logic lives in the same name space as the code it is managing. To address this, we use name resolution management to ensure that all Browser-Shield logic is inaccessible. This entails renaming certain variables and modifying the output of reflection in some cases.
Transparency The BrowserShield framework must also ensure that its presence is transparent to the original script’s semantics. Transparency additionally requires that we present to scripts the context they would have in the absence of BrowserShield. Achieved through Shadow copies, Preserving context mechanisms.
Flexibility The final goal of BrowserShield is to support flexible policy enforcement. This can be achieved by separating mechanism from policy Because the interposition logic itself is policy- driven, our system can be made incrementally complete. For example, if an undocumented API is discovered that can manipulate the document tree, we simply add a new policy to interpose on this API.
APPLICATIONS Comprehensive Link Translation Script Debugging Script Sandboxing Anti- Phishing Aids
Evaluation We evaluated BrowserShield’s ability to protect IE against all critical vulnerabilities for which Microsoft released patches in 2005 [Microsoft 2005]. Of the 29 critical patches that year, 8 are for IE, corresponding to 19 IE vulnerabilities. These vulnerabilities fall into three classes: IE’s handling of (i) HTML, script,or ActiveX components, (ii) HTTP, and (iii) images or other files
Evaluation Table II shows how many vulnerabilities there were in each area, and whether BrowserShield or another technology could provide patch-equivalent protection
Conclusion Script rewriting can protect web clients - Vulnerability-driven filtering - Transforms content, not browsers General framework BrowserShield can also serve as a platform for other new functionality on the Web,