Embed Size (px)
Citation preview
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
