Defeating Script Injection Attacks with Browser-Enforced Embedded Policies

Trevor Jim Nikhil Swamy Michael Hicks Defeating Script Injection Attacks with Browser-Enforced Embedded Policies Jason Froehlich September 24, 2008

Script Injection • Unauthorized script is added to web page, is executed by browser • Methods of attack: • Stored – Unvalidated user-generated content • Reflected – Embedded in URL • DOM based • http://vulnerable.site/welcome.html?name=Joe

Why is it still an issue? • Need to display content provided by users • Filtering is complicated • Need for rich content • Browsers work differently

Preventing Script Execution • Escape every '<' and '>' • Effective, but restricts rich content • Detect scripts • Difficult • Multiple Vectors • Encoding and Quoting • Browser Quirks

1. <html><head> 2. <script src="a.js"></script> 3. <script> ... </script> 4. <script for=foo event=onmouseover> ... </script> 5. <style>.bar{background-image:url("javascript:alert(’JavaScript’)");}</style> 6. </head> 7. <body onload="alert(’JavaScript’)"> 8. <img id=foo src="image.jpg"> 9. <a class=bar></a> 10. <div style="background-image: url(javascript:alert(’JavaScript’))">...</div> 11. <XML ID=I><X><C><![CDATA[<IMG SRC="javas]]><![CDATA[cript:alert(’XSS’);">]]> 12. <meta http-equiv="refresh" content="0;url=data:text/html;base64, PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K"> 13. <img src=javascript :alert('XSS')> 14. <img src=javascript:alert("3")> 15. <img src='java script:alert(1)'> 16. </body></html>

Creating a Solution • Observations: • Browsers perform script detection • Web developer knows which scripts are legit. • Solution: Browser-Enforced Embedded Policies • (BEEP)‏ • Browser only runs scripts deemed 'OK' by web app

Security Hook • Script added to head of each document • Evaluates each scripts before JS Interpreter • Makes decisions based on predefined policies • Hook must be run before all other scripts

Types of Policies • Whitelist • Hash of legit script • DOM Sandbox • App marks areas where malicious scripts possible • Unexpected Script Reporting • Script Classes

Complete Coverage • All approved scripts must be marked • Security hook must be implemented first • Set as first script in document

Deployment • Modify Browser • Insert handler where JS interpreter is called • Modify Server • Add security hook to each page • Incremental Implementation

Assumptions • Attacker has no special access to web app. • Attacker cannot modify data in transit • User trusts site enough to execute scripts • Site will tactfully endorse scripts

Whitelists • All valid scripts are known by developer • SHA-1 hash of each script is embedded in page • Hook compares generated hash to one provided • Hashing function provided by JS or browser lib. • Alternate Implementation: • Use full content of each script instead of hash • Reduces overhead, avoids collisions, larger pages

DOM Sandboxing • Developer knows areas where malicious content possible • Mark these areas with special tag - “noexecute” • Browser checks script's location in DOM tree for “noexecute” • Allows for unknown but trusted scripts • 3rd party ads

Implementing DOM Sandboxing • Place content into container marked as “noexecute” • Problem: Easy to break out of container <div class="noexecute">. . . possibly-malicious content. . . </div> </div><script>malicious script</script><div>

Improved DOM Sandboxing • Content encoded as JavaScript string • String embedded into document • Prevents escape from container <div class="noexecute" id="n5"></div> <script> document.getElementById("n5").innerHTML = "quoted possibly-malicious content " </script>

Other Issues • Scripts Generating Scripts • If parent script trusted, child is also • Third Party Scripts • Trust place holder script • All subsequent scripts will be trusted

Browser Implementation • Konqueror & Safari • 650 lines of code, plus 650 for hash implementation • Opera • Partial implementation in 79 lines, + 137 for hash • User JavaScripts • Firefox and Internet Exploder • Not currently implemented • Both have extensions similar to User JavaScripts, but allow other scripts to execute first

Web Application Implementation • Whitelist Policy • Find scripts in page • <script> elements, event handlers, hyperlinks • Insert whitelist and hook into document's head • DOM Sandboxing Policy • Pages must be in certain structure • Identify areas where user input can appear • Escape content of these areas • Insert security hook into document's head

Effectiveness • 100%, when implemented accurately • Verified by 61 known browser execution vectors • Possible weakness – Hash collision

Browser Overhead Benchmarks • All tests done in Safari 2.0.4 • Whitelists – 14.4% (0.2 seconds)‏ • DOM Sandboxing – 6.6% (.1 seconds)‏ • Delays would be maskd by network latency • Server Overhead Benchmarks - ?

Similar Projects • Script Keys – Gervase Markham • http://www.gerv.net/security/script-keys/ • Add random string to each valid script • Execute only those which contained string • Content Security Policy – Bsterne • http://people.mozilla.org/~bsterne/content-security-policy/ • Firefox extension - https://addons.mozilla.org/en-US/firefox/addon/7478 • Valid scripts placed in external file • Blocks all other scripts

Defeating Script Injection Attacks with Browser-Enforced Embedded Policies