Appsec XSS Case Study


Published on

Appsec XSS Case Study

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Appsec XSS Case Study

  1. 1. Application Security Security Verified Chapter 04 Cross-Site ScriptingMohamed Ridha Chebbi, © 2012 iCode information security All rights reserved
  2. 2. Introduction Security Verified• Cross-site scripting (or XSS) is the Godfather of attacks against other users.• It is by some measure the most prevalent web application vulnerability found in the wild.• there are many situations in which XSS does represent a critical security weakness within an application. It can often be combined with other vulnerabilities to devastating effect.• In some situations, an XSS attack can be turned into a virus or a self-propagating worm. © 2012 iCode information security All rights reserved
  3. 3. Reflected XSS Vulnerabilities Security Verified• A very common example of XSS occurs when an application employs a dynamic page to display error messages to users. Typically, the page takes a parameter containing the text of the message, and simply renders this text back to the user within its response.• This type of mechanism is convenient for developers, because it allows them to invoke a customized error page from anywhere in the application, without needing to hard-code individual messages within the error page itself. Example of Dynamic URL : Crafted URL<script>alert(‘xss’);</script> © 2012 iCode information security All rights reserved
  4. 4. Reflected XSS Vulnerabilities Security Verified• This type of simple XSS bug accounts for approximately 75% of the XSS vulnerabilities that exist in real-world web applications.• It is often referred to as reflected XSS because exploiting the vulnerability involves crafting a request containing embedded JavaScript which is reflected back to any user who makes the request. © 2012 iCode information security All rights reserved
  5. 5. Reflected XSS Vulnerabilities Security Verified © 2012 iCode information security All rights reserved
  6. 6. Stored XSS Vulnerabilities Security Verified• A different category of XSS vulnerability is often referred to as stored cross-site scripting. This version arises when data submitted by one user is stored within the application (typically in a back-end database) and then displayed to other users without being filtered or sanitized appropriately © 2012 iCode information security All rights reserved
  7. 7. Storing XSS in Uploaded Files Security Verified• If you can upload an HTML or text file containing JavaScript, and a victim views the file, then your payload will normally be executed. The following shows the raw response of an application that is vulnerable to stored XSS in this way : HTTP/1.1 200 OK Date: Sat, 5 May 2011 11:52:25 GMT Server: Apache Content-Length: 39 Content-Type: image/jpeg <script>alert(document.cookie)</script> Note : Even though the Content-Type header specifies that the message body contains an image, Internet Explorer overrides this and handles the content as HTML because this is what it in fact contains. © 2012 iCode information security All rights reserved
  8. 8. DOM-Based XSS Vulnerabilities Security VerifiedHere an example of the the process by which the attacker’s JavaScript gets executed is asfollows: ■ A user requests a crafted URL and containing attacker’s JavaScript. ■ The server’s response does not contain the attacker’s script in any form. ■ When the user’s browser processes this response, the script is executed. How can this series of events occur? The answer is that client-side JavaScript can access the browser’s document object model (DOM), and so can determine the URL used to load the current page. A script issued by the application may extract data from the URL, perform some processing on this data, and then use it to dynamically update the contents of the page. When an application does this, it may be vulnerable to DOM-based XSS. © 2012 iCode information security All rights reserved
  9. 9. DOM-Based XSS Vulnerabilities Security VerifiedFor example, suppose that the error pagereturned by the application contains the following:<script> var a = document.URL; a = unescape(a); document.write(a.substring(a.indexOf(“message=”) + 8, a.length));</script>This script parses the URL to extract the valueof the message parameter and simply writesthis value into the HTML source code of the page.Note : if an attacker craftsa URL containing JavaScriptthen this code will bedynamically written into thepage and executed. © 2012 iCode information security All rights reserved
  10. 10. Real-World XSS Attacks Security Verified AJAX : Ajax (or Asynchronous JavaScript and XML) is a technology used by some applications to create an enhanced interactive experience for users. Ajax is implemented using the XMLHttpRequest object. The following is a simple example of using Ajax within Internet Explorer to issue an asynchronous request and process its response: <script> var request = new ActiveXObject(“Microsoft.XMLHTTP”);“GET”, “”, false); request.send(); alert(request.responseText); </script> Ajax could be used to trivially violate the browser’s same origin policy, by enabling applications to retrieve and process data from a different domain. © 2012 iCode information security All rights reserved
  11. 11. Payloads for XSS Attacks Security Verified• Virtual Defacement• Injecting Trojan Functionality• Inducing User Actions hijacking a victim’s session © 2012 iCode information security All rights reserved
  12. 12. Payloads for XSS Attacks Security Verified• Exploiting Any Trust RelationshipsThere are several trust relationships that can sometimes be exploited in an XSS attack:■ If the application employs forms with autocomplete enabled, JavaScript issued by theapplication can capture any previously entered data that the user’s browser has stored inthe autocomplete cache.■ Some web applications recommend or require that users add their domain name to the“Trusted Sites” zone of their browser. This is almost always undesirable. For example,injecting the following code will cause the Windows calculator program to launch on theuser’s computer:<script> var o = new ActiveXObject(‘’); o.Run(‘calc.exe’);</script>■ etc. © 2012 iCode information security All rights reserved
  13. 13. Escalating the Client-Side Attack Security Verified• Log Keystrokes <script> document.onkeypress = function () { window.status += String.fromCharCode(window.event.keyCode); } </script>• Capture Clipboard Contents <script> alert(window.clipboardData.getData(‘Text’)); </script>• Steal History and Search Queries JavaScript can be used to perform a brute-force exercise to discover thirdparty sites recently visited by the user (using getComputedStyle API)• Enumerate Currently Used Applications JavaScript can be used to determine whether the user is presently logged in to third-party web applications. The trick is to attempt to dynamically load and execute the protected page as a piece of JavaScript: window.onerror = fingerprint; <script src=””></script> © 2012 iCode information security All rights reserved
  14. 14. Escalating the Client-Side Attack Security Verified• Port Scan the Local Network JavaScript can be used to perform a port scan of hosts on the user’s local network• Attack Other Network Hosts The following code checks for a specific image associated with a popular range of DSL routers: <img src=”” onerror=”notNetgear()“> © 2012 iCode information security All rights reserved
  15. 15. Preventing Reflected and Stored XSS Security Verified ■ Validate input. ■ Validate output. ■ Eliminate dangerous insertion points. © 2012 iCode information security All rights reserved
  16. 16. Validate Input Security Verified The application should perform context-dependent validation of input data, in as strict a manner as possible. Potential features to validate include the following: ■ That the data is not too long. ■ That the data only contains a certain permitted set of characters. ■ That the data matches a particular regular expression. Different validation rules should be applied as restrictively as possible to names, email addresses, account numbers, and so on, according to the type of data that the application is expecting to receive in each field. © 2012 iCode information security All rights reserved
  17. 17. Validate Output Security Verified Output data should be HTMLencoded to sanitize potentially malicious characters. HTML-encoding involves replacing literal characters with their corresponding HTML entities. This ensures that browsers will handle potentially malicious characters in a safe way, treating them as part of the content of the HTML document and not part of its structure. The HTML-encodings of the primary problematic characters are as follows: “ &quot; ‘ &apos; & &amp; < &lt; > &gt;In addition to these common encodings, in fact any character can be HTMLencodedusing its numeric ASCII character code, as follows: % % * * © 2012 iCode information security All rights reserved
  18. 18. HTML Encoding Example Security VerifiedOn the Java platform, there is no equivalent built-in API available; however, it is simpleto construct your own equivalent method using just the numeric form of encoding.For example: public static String HTMLEncode(String s) { StringBuffer out = new StringBuffer(); for (int i = 0; i < s.length(); i++) { char c = s.charAt(i); if(c > 0x7f || c==’“‘ || c==’&‘ || c==’<’ || c==’>’) out.append(“&#“ + (int) c + “;”); else out.append(c); } return out.toString(); } © 2012 iCode information security All rights reserved
  19. 19. Eliminate Dangerous Insertion Points Security VerifiedInserting user-controllable data directly into existing JavaScript should be avoidedwherever possible.When applications attempt to do this safely, it is frequently possible to bypass theirdefensive filters.A second location where user input should not be inserted is any other context in whichJavaScript commands may appear directly. For example: <img src=”userdata”> <img src=”foo.gif” onload=”userdata”>In this case an attacker can proceed directly to injecting JavaScript commands within thequoted string. For example: <img src=”javascript:alert(document.cookie)“> <img src=”foo.gif” onload=”alert(&apos;xss&apos;)“> © 2012 iCode information security All rights reserved
  20. 20. Preventing DOM-Based XSS Security Verified • Validate Input • Validate Output © 2012 iCode information security All rights reserved
  21. 21. Validate Input Security VerifiedIn many situations, applications can perform rigorous validation on the data beingprocessed. Indeed, this is one area where client-side validation can be more effectivethan server-side validation.Validating that the data about to be inserted into the document only containsalphanumeric characters and whitespace could be for example:<script> var a = document.URL; a = a.substring(a.indexOf(“message=”) + 8, a.length); a = unescape(a); var regex=/^([A-Za-z0-9+s])*$/; if (regex.test(a)) document.write(a);</script> © 2012 iCode information security All rights reserved
  22. 22. Validate Output Security Verified As with reflected XSS flaws, applications can perform HTML-encoding of user- controllable DOM data before this is inserted into the document. This will enable all kinds of potentially dangerous characters and expressions to be displayed within the page in a safe way. HTML encoding can be implemented in client-side JavaScript with a function like the following: function sanitize(str) { var d = document.createElement(‘div’); d.appendChild(document.createTextNode(str)); return d.innerHTML; } © 2012 iCode information security All rights reserved
  23. 23. Security Verified ThanksMohamed Ridha Chebbi, CISSP © 2012 iCode information security All rights reserved