Cross Site Scripting (XSS) Chaitanya Lakshmi

Topics to be Covered Overview of Cross Site Scripting & Description (A Basic Introduction - What is Cross Site Scripting?) How to Automate Tests for Cross Site Scripting Likely Places to Find XSS Vulnerabilities How to Prevent Cross Site Scripting on Your Website Additional Resources and Reading on Cross Site Scripting DOM Based XSS HTML Purifier Example for Non-Persistent XSS Example for Persistent XSS XSS Prevention Rules Output Encoding Rules XSS

Overview of Cross Site Scripting & Description (A Basic Introduction - What is Cross Site Scripting?) XSS is an attack using a browser side scripting language (usually JavaScript). The goal of the attacker is to make the malicious script appear to be from the site being attacked, so the user's browser can't tell the script being executed is not meant to be aprt of the site they are viewing. This is usually accomplished by an attacker by submitting specially crafted values into the target site's URL or web forms, or anywhere user generated content is displayed on the site. Users can fall into an XSS attack primarily in two ways: Tricking a user to click on a link, via having them view an , or having them view another site under attacker control. This could be as benign as a forum where image tags are allowed, and an attacker posts something like Creating an XSS attack and storing it on the target site, such as in a forum post, profile, or other method. This type of attack may also be self-propagating, creating an XSS worm. There are two broad attack surfaces which must be protected from XSS: The first is the users browser environment, and any JavaScript or other code which is executed by the browser. The second is server side. Browser attacks are executed via variables like the http referrer (page the user was last on and clicked from), or other http type methods such as document.location or document.URL.

How to Automate Tests for Cross Site Scripting Crawl the application, capturing all GET and POST fields For each GET and POST, try every XSS variant which can be thought of For each page in the application, test all sections in the likely locations of XSS section. If any show an alert response, consider XSS having been found

Likely Places to Find XSS Vulnerabilities XSS is found in many website locations, not all of which are obvious. This lists all locations where XSS may be found: HTTP referrer objects The URL GET parameters POST parameters Window.location Document.referrer document.location document.URLUnencoded All headers Cookie data Potentially data from your own database (if not properly validated on input)

How to Prevent Cross Site Scripting on Your Website XSS can only be prevented by carefully sanitizing all input which is not known to be secure. Classes of input which is known NOT to be secure include: HTTP referrer objects The URL GET parameters POST parameters Window.location Document.referrer document.location document.URLUnencoded All headers Cookie data Potentially data from your own database (if not properly validated on input)

Alternate control statement syntax for templates In templates, the alternate control statement syntax using : instead of brackets is allowed. There should not be a space between the closing paren after the control keyword, and the colon, and HTML/PHP inside the control structure should be indented. For Example:

DOM Based XSS The XSS attacks that rely on server side embedding of user data are categorized into “non-persistent” (or “reflected”) and “persistent” (or “stored”). It is thus suggested that the third kind of XSS, the one that does not rely on server side embedding, be named “DOM Based XSS”.

HTML Purifier HTML Purifier is a standards-compliant HTML filter library written in PHP. HTML Purifier will not only remove all malicious code (better known as XSS) with a thoroughly audited, secure yet permissive whitelist. It will also make sure your documents are standards compliant, something only achievable with a comprehensive knowledge of W3C's specifications.

Example for Non-Persistent XSS index.php: <?php $name = $_GET['name']; echo "Welcome $name "; echo " Click to Download "; ?> Example 1: Now the attacker will craft an URL as follows and send it to the victim: index.php?name=guest alert('attacked') When the victim load the above URL into the browser, he will see an alert box which says ‘attacked’. Even though this example doesn’t do any damage, other than the annoying ‘attacked’ pop-up, you can see how an attacker can use this method to do several damaging things.

Example for Non-Persistent XSS Contd... Example 2: For example, the attacker can now try to change the “Target URL” of the link “Click to Download”. Instead of the link going to “xssattackexamples.com” website, he can redirect it to go “not-real-xssattackexamples.com” by crafting the URL as shown below: index.php?name= window.onload = function() { Var link=document.getElementsByTagName("a"); link[0].href=" } In the above, we called the function to execute on “window.onload”. Because the website (i.e index.php) first echos the given name and then only it draws the tag. So if we write directly like the one shown below, it will not work, because those statements will get executed before the tag is echoed index.php?name= Var link=document.getElementsByTagName("a");link[0].href="

Example for Non-Persistent XSS Contd... Normally an attacker tends not to craft the URL which a human can directly read. So he will encode the ASCII characters to hex as follows. index.php?name=%3c%73%63%72%69%70%74%3e%77%69%6e%64%6f%77%2e%6f %6e%6c%6f%61%64%20%3d%20%66%75%6e%63%74%69%6f%6e%28%29%20 %7b%76%61%72%20%6c%69%6e%6b%3d%64%6f%63%75%6d%65%6e%74%2e %67%65%74%45%6c%65%6d%65%6e%74%73%42%79%54%61%67%4e%61%6d %65%28%22%61%22%29%3b%6c%69%6e%6b%5b%30%5d%2e%68%72%65%66 %3d%22%68%74%74%70%3a%2f%2f%61%74%74%61%63%6b%65%72%2d%73 %69%74%65%2e%63%6f%6d%2f%22%3b%7d%3c%2f%73%63%72%69%70%74% 3e which is same as: index.php?name= window.onload = function() { Var link=document.getElementsByTagName("a");link[0].href=" xssattackexamples.com/"; xssattackexamples.com/ }

Example for Non-Persistent XSS Contd... Example 2: For example, the attacker can now try to change the “Target URL” of the link “Click to Download”. Instead of the link going to “xssattackexamples.com” website, he can redirect it to go “not-real-xssattackexamples.com” by crafting the URL as shown below: index.php?name= window.onload = function() { Var link=document.getElementsByTagName("a"); link[0].href=" } In the above, we called the function to execute on “window.onload”. Because the website (i.e index.php) first echos the given name and then only it draws the tag. So if we write directly like the one shown below, it will not work, because those statements will get executed before the tag is echoed index.php?name= Var link=document.getElementsByTagName("a");link[0].href="

Persistent XSS There are two types of users: “Admin” and “Normal” user. When “Admin” log-in, he can see the list of usernames. When “Normal” users log in, they can only update their display name. In case of persistent attack, the code injected by the attacker will be stored in a secondary storage device (mostly on a database). The damage caused by Persistent attack is more than the non-persistent attack. Session HTTP protocol is a stateless protocol, which means, it won’t maintain any state with regard to the request and response.All request and response are independent of each other. But most of the web application don’t need this. Once the user has authenticated himself, the web server should not ask the username/password for the next request from the user. To do this, they need to maintain some kind of states between the web-browser and web-server which is done through the “Sessions”.

Persistent XSS Contd... When the user login for the first time, a session ID will be created by the web server and it will be sent to the web-browser as “cookie”. All the sub-sequent request to the web server, will be based on the “session id” in the cookie. Example: If a Normal User Logs into the site and Tried to enter any Textbox (Example: Displayname Textbox) value as Below, My Name By clicking on Submit / Save button, The above information entered by the attacker will be stored in the database (persistent).

Persistent XSS Contd... When the admin log-in to the system, he/she can see a link named “My Name” along with other usernames. When admin clicks the link, it will send the cookie which has the session ID, to the attacker’s site. Now the attacker can post a request by using that session ID to the web server, and he can act like “Admin” until the session is expired. The cookie information will be something like the following: xss.php?c=PHPSESSID%3Dvmcsjsgear6gsogpu7o2imr9f3 Once the hacker knows the PHPSESSID, he can use this session to get the admin privilege until PHPSESSID expires. To understand this more, we can use a firefox addon called “Tamper Data”, which can be used to add a new HTTP header called “Cookies” and set the value to “PHPSESSID=vmcsjsgear6gsogpu7o2imr9f3″.

XSS Prevention Rules Never Insert Untrusted Data Except in Allowed Locations HTML Escape Before Inserting Untrusted Data into HTML Element Content Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values Use an HTML Policy engine to validate or clean user-driven HTML in an outbound way Prevent DOM-based XSS Use HTTPOnly cookie flag

XSS Prevention Rules Sample Code

Output Encoding Rules XSS

References Drupal Filters HTML to prevent cross-site-scripting (XSS) vulnerabilities. CERT Advisory CA Malicious HTML Tags Embedded in Client Web Requests”, CERT, February 2nd, “Cross Site Scripting Explained”, Amit Klein, June “Cross-Site Scripting”, Web Application Security Consortium, February 23rd, “Cross Site Scripting (XSS) Flaws”, The OWASP Foundation, updated “Thor Larholm security advisory TL#001 (IIS allows universal CrossSiteScripting)”, Thor Larholm, April 10th,

References Contd... “ISA Server Error Page Cross Site Scripting”, Brett Moore, July 16th, (see also Microsoft Security Bulletin MS and a more elaborate description in “Microsoft ISA Server HTTP error handler XSS”, Thor Larholm, July 16th, “Bugzilla Bug XSS vulnerability in internal error messages”, reported by Michael Krax, December 23rd, “The Cross Site Scripting FAQ”, Robert Auger, May 2002 (revised August 2003)