Web Shield Enabling Various Web Defense Techniques without
Web. Shield: Enabling Various Web Defense Techniques without Client Side Modifications Zhichun Li, Tang Yi, Yinzhi Cao, Vaibhav Rastogi, Yan Chen, Bin Liu, and Clint Sbisa NEC Laboratories America, Inc. Northwestern University Tsinghua University
Web Has Become a Primary Target Drive by Download Cross site scripting Cross Site Request Forgery Cross-Origin Java. Script Capability Leaks 2
Desire a General Middlebox • Existing web defense techniques need browser/client modification Existing Web Defense Approaches Client modification Slow adoption • Advocate middlebox approaches Client-side Middlebox heterogenous & co-exist with other software clean installation high maintenance overhead centralized control easy update and VM user voluntary update management 3
General Design Principles for Middlebox • Principles – Principle I: general middlebox should enable various protection mechanisms – Principle II: avoid client-side deployment – Principle III: containment of untrusted script execution – Principle IV: should not sacrifice user experience 4
Existing Middlebox Approaches • Browser. Shield – Code rewriting: rewrite HTML and Java. Script code with policy checking wrappers – Only applies to known browser vulnerabilities – Hard to be extended to support other defense mechanisms • Spy. Proxy – Actively execute the web pages in a proxy sandbox – Applies to both known and unknown vulnerabilities – But only detect deterministic exploits 5
Evade Existing Approaches function attack. X() { // exploit an unknown vulnerability, // so Browser. Shield cannot be applied. . . } var attackcalled=false; function load. Attack() { var el=document. get. Element. By. Id("Evil"); // user events to bypass Spy. Proxy el. add. Event. Listener("mouseover", check. Mouse, false); } function check. Mouse() { Trigger the if (! attackcalled) { attack through attackcalled=true; mouse events window. set. Timeout(attack. X, 0); } } Very Easy to Implement 6
Outline • • Our Design Implementation Evaluation Conclusion 7
Our Design Client Browser Java. HTML CSS Script Parser Engine DOM Render Engine User Interface 8
Our Design Client Browser Java. HTML CSS Script Parser Engine DOM Render Engine User Interface 9
Our Design Client Browser Java. HTML CSS Script Parser Engine DOM Render Engine User Interface 10
Our Design Java. HTML CSS Script Parser Engine DOM Render Engine User Interface 11
Our Design Proxy sandbox Java. Script Render Agent DOM Sync visual effects through encoded DOM updates Java. HTML CSS Script Parser Engine DOM Render Engine DOM Encoder User Interface Browser Controller Detection Engine Web Proxy 12
Initial Page Render Client Browser Render Agent URI Request Transformed Resp web Web Proxy Shadow Browser HTML Resp <!—ey. Jk. YXRh. Ijp 7 f. Swi d. Hlw. ZSI 6 In. N 0 e. Wxl. U 2 h 4 i. Oltdf. Q==--> <script id="DOM 1"> __dp. apply("DOM 1“) </script> 13
Dynamic HTML Interaction Support input Client Browser wrap as JS events Web Proxy web DOM visual updates Shadow Browser • Latency added – Communication delay – DOM update delay • DOM tree update location – Element ID – Location vector starting from the root of the tree 14
Implementation • Use Webkit to implement Shadow browser • Current sandbox based on SELinux • Session manager in Python 15
Outline • • Our Design Implementation Evaluation Conclusion 16
Evaluation • Environment Setup – Web Proxy: 2. 5 GHz Intel Xeon server – Web Browser on Core 2 2. 66 GHz • Evaluation Metrics – Compatibility – Performance (user transparency) • Latency • Memory • Communication overhead – Drive-by-download detect demonstration 17
Evaluation • Compatibility – 91 out of Alexa top 100 web sites – 19 out of Alexa top 20 web sites – Reasons for not compatible websites • Not supported features • Stability of the prototype 18
Latency Overhead • Initial page rendering – Evaluate Alexa top 100 sites – Render start: median +134 ms, 90 th percentile +1. 08 sec – Render end: median +382 ms, 90 th percentile +2. 46 sec Chrome render start and end time 19
Latency Overhead • Interactive Performance for Dynamic HTML – Microbenchmarks – Test on a real Java. Script game: Java. Script Game – connect 4 Additional Delay Start Game Move Mouse Drop a Piece Game Over 41 ms 7 ms 10 ms 7 ms 20
Memory and Communication Overhead • Memory overhead • Communication overhead 21
Usefulness Demonstration • Drive-by-download detection – Implement both policy-based and behavior-based detection • Policy-based: check the parameters of Java. Script API calls and the parsing process • Behavior-based: check a list of abnormal behaviors similar to Spy. Proxy – Evaluate eight vulnerabilities with Alexa top 500 web sites. Detection plug-ins False Negative False Positive Policy Engine 0 1/500 Behavior Engine 0 0/500 22
Conclusion • We design, implement and evaluate Web. Shield – A general middlebox that enables various web defense mechanisms – Run Java. Script inside the middlebox, and thus reduce the attack surface – No client modification – Small overhead for latency, communication and memory remain good user experience 23
Advertisement • Positions available for system people (OS, Network, and Security) in NEC Research Labs – Full-time – Interns
Q&A
- Slides: 25