XSS Cross Site Scripting Jörg Schwenk Horst Görtz Institute Ruhr-University Bochum Dagstuhl 2009
http://en.wikipedia.org/wiki/crosssite_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 DNS Internet Webserver Application Server Database PDF Malware Rendering Javascript AJAX engine Flash Real PKI
Browser-based protocols Rendering Javascript AJAX engine Internet Webserver Application Server Database
Browser-based protocols 3 4: CSS www.css-repos.com Rendering Javascript AJAX engine 1 2: HTML+JS 5 6: JS-Lib www.example.org library.js.net
Web Origins and Browser DOM window document body document.location defines HTML JS loaded from loaded from www.example.org www.example.org grants access rights to origin www.example.org CSS loaded from www.css-repos.com JS-Lib loaded from library.js.net
Browser-based Cryptographic protocols: SOP (Same Origin Policy) Document1 Document2 Cookies Form Script1 Name Account Amount Script1: GetCookie Script2: Modify Account Script3: Send/ Request data Schwenk 443232 66,43 Origin: https://banking.bank.com:443 Origin: http://attacker.org:80 Access Denied SOP
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 Webseiten
Reflected 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 type="text/javascript">alert("xss")</script></p>
Reflected XSS (non-persistent) 3: GET+ JS-XSS victim.com Rendering Javascript AJAX engine 4: HTML + JS-XSS (active) 1 2: HTML + JS-XSS (inactive) attacker.org
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
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 Quelle: http://www.heise.de/security/result.xhtml?url=/security/news/meldung/54272&words=ebay%20scripting
Stored XSS (persistent) 2: GET victim.com Rendering Javascript AJAX engine 3: HTML + JS-XSS 1: HTML + JS-XSS 1 attacker.org
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
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> Amit Klein, http://www.webappsec.org/projects/articles/071105.shtml
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> Amit Klein, http://www.webappsec.org/projects/articles/071105.shtml
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> Amit Klein, http://www.webappsec.org/projects/articles/071105.shtml
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> Amit Klein, http://www.webappsec.org/projects/articles/071105.shtml
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 Amit Klein, http://www.webappsec.org/projects/articles/071105.shtml
DOM based XSS (Local XSS) GET welcome.html 3: GET HTTP 1.1 host: www.vulnerable.site victim.com Rendering Javascript AJAX engine 4: HTML 1: GET 5: XSS executed during (local) rendering 2: HTML + <a href= http://www.vulnerable.site/welcome.html# JS-XSS name= <script>alert(document.cookie)</script> >Klick (inactive) me!</a> attacker.org
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: Vela 2009: Overlong Google Analytics tracking code snippets
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 Therefore, client side filtering is applied
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 Request URL IE XSS Filter HTML Markup Network Stack
Client Side: Webkit/Google Chrome XSS Auditor Works similar to IE XSS Filter Different position HTML Parser Webkit XSS Auditor Javascript Engine Network Stack
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 Request URL to Trusted Site NoScript Rewritten URL to Trusted Site Network Stack
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: X-Content-Security-Policy: allow https://*:443
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... But this can of course be relaxed
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. JSAgents/IceShield: see below
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
Ausblick: Cross Site Request Forgery Schritt 2: Einloggen des Opfers bei Hotmail. 1: Login auf NY Times Webseite 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. nytimes.com Victim 2: Anschauen der Webseite des Angreifers 38 http://www.freedom-totinker.com/blog/wzeller/popular-websitesvulnerable-cross-site-request-forgery-attacks Microsoft Identity Managment Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit attacker.org
Ausblick: Cross Site Request Forgery 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. 39 http://www.freedom-totinker.com/blog/wzeller/popular-websitesvulnerable-cross-site-request-forgery-attacks Microsoft Identity Managment Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit