WebShield: Enabling Various Web User Defense Techniques without Client Side Modifications

1. WebShield: Enabling Various Web User Defense Techniqueswithout Client Side Modifications Yan Chen Lab for Internet and Security Technology (LIST) Northwestern Univ.

2. WebShield: Enabling Various Web User Defense Techniques Motivation Design Principle Architecture and Mechanisms Security Analysis Implementation Evaluation Conclusions 2 2

3. Motivation • Browser vulnerabilities have been a major target for various of attacks • Drive-by-download attacks that exploit browser vulnerabilities to comprise machine • JavaScript capability leaking for information stolen. • Many client side approaches require browser enhancement But… slow user adoption and users still use legacy browsers

4. Motivation • Goal: Design a middlebox approach which protect web users transparently • Comparison of middlebox and client side solutions

5. Limitations of Existing Middle Box Approaches • BrowserShield: cannot detect unknown vulnerabilities • Cannot enable the detection/protection approaches that require internal states of browsers or underlying OS. • SpyProxy: as admitted in their paper, cannot cope with the non-determinism or user events

6. Examples bypass existing approaches Javascript snippet var attackcalled=false; function attackX() { // exploit an unknown vulnerability so BrowserShield fail … } function loadAttack() { var el=document.getElementById(“Evil”); //use user events to bypass SpyProxy el.addEventListener(“mouseover”,checkMouse,false); } function checkMouse() { if (not attackcalled) { attackcalled=true; window.settimeout(attackX,0); } }

7. WebShield: Enabling Various Web User Defense Techniques Motivation Design Principle Architecture and Mechanisms Security Analysis Implementation Evaluation Conclusions 7 7

8. Design Principle A general framework should enable various different protection mechanisms against from as many attacks as possible. 8

9. Design Principle Cont. • No additional program on clients. • Do not allow any untrustedscript execution at the client side. • Leverage the client side browser as little as possible • User experience should not be sacrificed

10. Application Mashup Attacks • Attackers can control other mashups in the same integrator.

11. Capability Leaks • Browser bugs may cause inter context leaks • Attacker can use unintentionally leaked pointer to get access to powerful functions in the DOM • Affect non vulnerable sites too • A Webkit vulnerability: page navigation leaks document pointer of new site to old site • A phishing site may steal your emails this way

12. A vulnerability in WebKit • Phising site to gmail.com creates an exploit function in an iframe • In its parent frame, it stores a reference to this function • Now navigates to an honest website • Finally calls the exploit function http://gmail.com

13. Web Page Execution Flow

14. Basic Ideas • Reduce the functionalities used on client browsers, and execute most exploited parts on the web proxy. Proxy the visual effects at DOM level.

15. WebShield: Enabling Various Web User Defense Techniques Motivation Design Principle Architecture and Mechanisms Security Analysis Implementation Evaluation Conclusions 15 15

16. WebShield Architecture

17. Design • Initial Page Rendering Process • Dynamic HTML Interaction Support • Communication Between Client Browser and the Proxy • Sandbox of the Shadow Browser Instance

18. Initial Page Rendering Process For HTML objects, w/ embedded Javascript and CSS files

19. Initial Page Rendering Process For other objects

20. Dynamic HTML Interaction Support

21. Communication Between Client Browser and the Proxy • Encoding the DOM data structure in JSON • Encapsulating the DOM updates in a HTML page during the initial page rendering • Handling Dynamic HTML effects using AJAX • Finding the update location in the DOM tree

22. Sandbox of the Shadow Browser Instance • Different Sandbox techniques can be incorporated to WebShield • OS sandboxes: SELinux • VM: Xen • Used as the basis of behavior engine to detect unknown attacks • Also applied signature engine for detection of existing vulnerabilities

23. WebShield: Enabling Various Web User Defense Techniques Motivation Design Principle Architecture and Mechanisms Security Analysis Implementation Evaluation Conclusions 23 23

24. Security Analysis • Subverting the Sandboxes really hard • Step 1: Compromise the shadow browser, which means she must to bypass the detection of known vulnerabilities as well as the behavior detection engine. • Step 2: Exploit another vulnerability in the sandbox to escalate her privileges and take control of the host OS or VMM. • Potential DDoS Attack • Limit the number of HTML webpages that can be concurrently opened from a single IP. • Compatibility with Other Security Protection Mechanisms • Same Origin Policy (Yes) • Host Anti-virtus Protector (Yes)

25. WebShield: Enabling Various Web User Defense Techniques Motivation Design Principle WebShield Architecture and Mechanisms Security Analysis Implementation Evaluation Conclusions 25 25

26. Implementation DOM Instrumentation (Using WebKit, 3800 lines of C++) Session Manager Implementation (3700 lines of Python) Sandbox Implementation (SELinux) Drive-By-Download Detection Policy Engine: semantic based filtering Behavior Engine: similar to HoneyMoney 26

27. WebShield: Enabling Various Web User Defense Techniques Motivation Design Principle Architecture and Mechanisms Security Analysis Evaluation Conclusions 27 27

28. Evaluation • Drive-By-Download Evaluation • Latency Overhead • Communication Overhead • Memory Overhead • Interactive Performance for Dynamic HTML • A Real Game

29. Drive-By-Download Evaluation • Extremely low false positive rate

30. Latency Overhead • Measure latency overheads for top 100 websites from Alexa • CDF of Rendering Start Time Firefox Chrome • Median difference: 133.5 ms • 90 percentile difference: 1.083 s

31. Latency Overhead • CDF of Rendering End Time Chrome Firefox • Median difference: 382 ms • 90 percentile difference: 2.459 s

32. Communication Overhead • Communication overhead when rendering some of the most complex websites. • Mixed Results • JSON less dense than HTML • Some JavaScript not transferred

33. Memory Overhead • Memory overhead when rendering some of the most complex websites. • At par with native parsing • Preparsed content takes less memory • The size of our JavaScript library may be substantial for smaller pages

34. Interactive Performance for Dynamic HTML • Major Costs • Communication Delay • Emulate different network latencies and different transfer sizes to study delay in response to a click event • DOM update delay: • Measure the time required to update a 2 KB size text node (positioned at first child of body) 10,000 times. • Found to be negligible

35. Interactive Performance for Dynamic HTML • Communication delay is unperceivable for decent network latencies and data transfer sizes

36. A Real Game • Macrobenchmark test • Measure the performance of a real application • Connect 4: a game from front page of a popular games’ website (Ranked First in Google Search of “JavaScript Game”) • Delays are fairly small

37. WebShield: Enabling Various Web User Defense Techniques Motivation Design Principle WebShield Architecture and Mechanisms Security Analysis Evaluation Conclusions 37 37

38. Conclusions • We design, implement and evaluate WebShield: a general middlebox framework that can enable various security protection mechanisms. • We show they are effective to defend Web attacks w/ • Small overhead for latency, communication, and memory • Good interactive performance for dynamic HTML • No client modification

39. Q & A? Thanks! 39

40. JSON • JavaScript Object Notation (JSON) is a lightweight data-interchange format • Equivalent of XML • It is easy for humans to read and write, and easy for machines to parse and generate • It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition • JSON is a text format that is completely language-independent, but uses conventions familiar to programmers of the popular programming languages • JSON is built on two structures: • A collection of name/value pairs: like object, dictionary, or hashtable • An ordered list of values: like array, vector, list, or sequence • These properties make JSON an ideal data-interchange language

41. Threat Model & Assumption • Any webpage going through the proxy can potentially be malicious. • WebShield is mainly designed to protect enterprise networks. • We assume that most web users are benign. (DDOS to the WebShield from users is not in consideration.)

42. Q&A • Suggestions?