XSS – Cross Site Scripting
Jörg Schwenk
Horst Görtz Institute
Ruhr-University Bochum Dagstuhl 2009
http://en.wikipedia.org/wiki/Cross-site_scripting
• Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications that enables
attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites accounted for roughly 80.5% of all security vulnerabilities documented by Symantec as of 2007.[1] Their
effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner.
Overview
1. Web Origins, Browser DOM and the Same Origin Policy
2. Reflected XSS
3. Stored XSS
4. DOM XSS
5. Classical Countermeasures
6. JSAgents
Browser-based protocols
Internet Webserver A J A X e n g in e R e n d e ri n g J a v a s c ri p t F la s h R e a l P D F M a lw a re Application Server Database DNS PKIBrowser-based protocols
Internet Webserver A J A X e n g in e R e n d e ri n g J a v a s c ri p t Application Server DatabaseBrowser-based protocols
2: HTML+JS www.example.org A J A X e n g in e R e n d e ri n g J a v a s c ri p t 1 www.css-repos.com library.js.net 4: CSS 3 6: JS-Lib 5Web Origins and Browser DOM
window
document document.location
HTML loaded from www.example.org
defines
JS loaded from www.example.org
CSS loaded from www.css-repos.com
JS-Lib loaded from library.js.net
body
grants access rights to origin www.example.org
Browser-based Cryptographic protocols:
SOP (Same Origin Policy)
Document1
Cookies Form
Name Account Amount Schwenk 443232 66,43 Script1 Document2 Script1: GetCookie Script2: Modify Account Script3: Send/ Request data
SOP
Origin: https://banking.bank.com:443 Origin: http://attacker.org:80
Overview
1. Web Origins, Browser DOM and the Same Origin Policy
2. Reflected XSS
3. Stored XSS
4. DOM XSS
5. Classical Countermeasures
6. JSAgents
Reflected XSS (non-persistent)
• Angreifer übergibt Skriptcode über einen eigens präparierten Hyperlink an das Opfer • Typisches Angriffsziel: Suchfunktionen in WebseitenReflected XSS (non-persistent)
• Normale URL, die eine Suche auf der Webseite triggert:
http://example.com/?suche=Suchbegriff
• Resultat: <p>Sie suchten nach: Suchbegriff</p>
• Präparierte URL: http://example.com/?suche=<script type="text/javascript">alert("XSS")</script>
• Resultat: <p>Sie suchten nach: <script
Reflected XSS (non-persistent)
A J A X e n g in e R e n d e ri n g J a v a s c ri p t victim.com attacker.org 4: HTML + JS-XSS (active) 3: GET+ JS-XSS 2: HTML + JS-XSS (inactive) 1Overview
1. Web Origins, Browser DOM and the Same Origin Policy
2. Reflected XSS
3. Stored XSS
4. DOM XSS
5. Classical Countermeasures
6. JSAgents
Stored XSS (persistent)
Beispiel eBay
Phisher erstellt Angebot
Bettet im Angebot „bösartigen“ Code ein
Code kompromittiert „Bieten-Button“
Benutzer wird zur Eingabe seiner Zugangsdaten aufgefordert, wobei diese Seite vom
Angreifer stammt
Benutzer gibt seine Zugangsdaten preis
Stored XSS (persistent)
A J A X e n g in e R e n d e ri n g J a v a s c ri p t victim.com attacker.org 3: HTML + JS-XSS 2: GET 1: HTML + JS-XSS 1Overview
1. Web Origins, Browser DOM and the Same Origin Policy
2. Reflected XSS
3. Stored XSS
4. DOM XSS
5. Classical Countermeasures
6. JSAgents
DOM based XSS (Local XSS)
Consider the following webpage located at
http://www.vulnerable.site/welcome.html <HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos, document.URL.length)); </SCRIPT> <BR>
Welcome to our system …
</HTML>
DOM based XSS (Local XSS)
Typical use: http://www.vulnerable.site/welcome.html?name=Joe <HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos, document.URL.length)); </SCRIPT> <BR>Welcome to our system …
</HTML>
DOM based XSS (Local XSS)
Result of: http://www.vulnerable.site/welcome.html?name=Joe <HTML> <TITLE>Welcome!</TITLE> Hi Joe <BR>Welcome to our system …
</HTML>
DOM based XSS (Local XSS)
Result of: http://www.vulnerable.site/welcome.html?name= <script>alert(document.cookie)</script> <HTML> <TITLE>Welcome!</TITLE> Hi <script>alert(document.cookie)</script> <BR>Welcome to our system …
</HTML>
DOM based XSS (Local XSS)
Avoid detection by server side filtering:
http://www.vulnerable.site/welcome.html#name= <script>alert(document.cookie)</script>
• # indicates that the string following this character is a fragment
identifier, i.e. it is only an indication to the browser which part of the document to display
• The string following # is thus never sent to the server, but it is stored in DOM-properties like document.location or document.URL
DOM based XSS (Local XSS)
A J A X e n g in e R e n d e ri n g J a v a s c ri p t victim.com attacker.org 4: HTML 3: GET 2: HTML + JS-XSS (inactive) 1: GET<a href=″http://www.vulnerable.site/welcome.html#
name= <script>alert(document.cookie)</script>″>Klick me!</a>
GET welcome.html HTTP 1.1 host: www.vulnerable.site
5: XSS executed during (local) rendering
Overview
1. Web Origins, Browser DOM and the Same Origin Policy
2. Reflected XSS
3. Stored XSS
4. DOM XSS
5. Classical Countermeasures
6. JSAgents
Server Side: Blocking
• If unsolicited content (e.g. Overlong cookies) is detected, processing of the http request is blocked.
• Instead, e.g. A static webpage can be displayed.
• Can be misused to perform DoS attacks:
Server Side: Stripping and Replacing
• PHP strip_tags() removes potentially dangerous characters
from user input
• If this seems too rigid, $allowable_tags can be defined; this may open doors for XSS in single web applications
• Stripping substrings is complex: e.g. Stripping „fromCharCode“ from „fromCfromCharCodeharCode“
• Character replacement is more reliable, but can nebertheless be circumvented (Amazon AWS attack)
Server Side: Escaping
• Potentially dangerous characters like < are prepended with a
backslash character: \<
• Potential problems with unicode characters may lead to SQLi • innerHTML and CSS attacks
Server Side: Encoding
• PHP htmlentities() and htmlspecialchars() encode
potentially dangerous characters
• May be bypassed with e.g. UTF7 encoding of attack vectors:
+Adw-script+AD4-alert(1)+Adw-/script+AD4-Server Side: Rewriting
• HTMLPurifier for PHP, AntiSamy for Java, SafeHTML for Windows Server environments
• Web application want to allow posting of harmless HTML • Different approaches:
– Only regular expressions: broken
– HTMLPurifier: Build new DOM tree, match this tree aganinst XHTML DTD, remove non-matching elements
– Google Caja: rewrites Javascript (+HTMl + CSS) code, may result in code expansion (1 line -> 130 lines)
Client Side Filtering
• Server does not see complete code that is rendered by the browser – innerHTML
– DOM XSS
– Flash Parameters
Client Side: IE XSS Filter
• Checks for matches between Request URL fragments and the resulting HTML markup
• Problems with detecting fragmented attack vectors (because they are only
completed by the markup parser)
Markup Parser
Network Stack
IE XSS Filter
Request URL
Client Side: Webkit/Google Chrome XSS
Auditor
• Works similar to IE XSS Filter • Different positionHTML
Parser
Network Stack
Webkit
XSS
Auditor
Javascript
Engine
Client Side: NoScript XSS Filter (Firefox)
• Rewrites URL parameters if URL request goes to a trusted site • insecure.php?a="><img/ src= onerror=alert(1) • Is changed to • insecure.php?a=> img%2Fsrc= ONERROR=ALERT 1 #some_random_number
HTML Parser
Network Stack
NoScript
Request URL to Trusted Site
Content Security Policy
https://wiki.mozilla.org/Security/CSP/Specification
• Example 2: Auction site wants to allow images from anywhere, plugin content from a list of trusted media providers (including a content
distribution network), and scripts only from its server hosting sanitized JavaScript:
X-Content-Security-Policy: allow 'self'; img-src *; object-src media1.com media2.com *.cdn.com; script-src trustedscripts.example.com
• Example 4: Online payments site wants to ensure that all of the content in its pages is loaded over SSL to prevent attackers from eavesdropping on requests for insecure content:
IFrame Sandboxing
Sandboxed Iframes: New feature in HTML5 • No script execution
• No plugin execution
• No top oder parent access • No form submissions
• ... Only display static HTML
Javascript Sandboxing
• JSReg: purely written in Javascript, uses regular expressions, often broken.
• Dojo Sandbox: blocks access to sensitive DOM properties, broken in 2010 (e.g. Unicode escapes)
• Rhino and LiveConnect: Run Javascript inside an Java applet, which has its own Javascript parser – should be safe, broken by Heiderich et.al.
Overview
1. Web Origins, Browser DOM and the Same Origin Policy
2. Reflected XSS
3. Stored XSS
4. DOM XSS
5. Classical Countermeasures
6. JSAgents
Microsoft Identity Managment
Jörg Schwenk Lehrstuhl für Netz- und
Datensicherheit 38
Ausblick: Cross Site Request Forgery
Schritt 2: Einloggen des Opfers beiHotmail.
nytimes.com
attacker.org Victim
1: Login auf NY Times Webseite
2: Anschauen der Webseite des Angreifers
3: http-Link (z.B. in einem <img>-Tag) enthält Query-String mit dem Befehl, eine E-Mail an collect@attacker.org zu senden.
http://www.freedom-to- tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks
Microsoft Identity Managment
Jörg Schwenk Lehrstuhl für Netz- und
Datensicherheit 39
Ausblick: Cross Site Request Forgery
http://www.freedom-to- tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks
1. ING Direct (ingdirect.com) – Status: Fixed
2. YouTube (youtube.com) – Status: Fixed
3. MetaFilter (metafilter.com) – Status: Fixed
4. The New York Times (nytimes.com) – Status: Fixed.
