Cross Site Scripting

Badrish Dubey
badrish007@gmail.com
securetechpoint.blogspot.in
 INTRODUCTION
 XSS was firstly discovered around 1996 and is still in the top
ten vulnerability list for the web applications
 Rated 2nd in OWASP (Open Web Application Security
Project) TOP 10
 8th in the list of threat classification v2.0 for WASC (Web
Application Security Consortium)
 Grouped under client side ATTACK
 What XSS can do!!!!
 Stealing cookies, this is also known as Session Hijacking.
 Redirecting the users to another websites.
 Displaying completely different contents on your website.
 Performing port scans of the customer’s internal network, which
may lead to a full intrusion attempt.
 Denting the REPUTATION and GOODWILL of the organization.
 Can lead Huge PENALITY AMOUNT which can affect the
continuity of business
 Different flavors of XSS

1. Reflected Cross Site Scripting (Non Persistence)

2. Stored Cross Site Scripting (Persistence)
3. DOM based Cross Site Scripting

In rest of the presentation we would be talking about the

Reflected and Stored Cross site scripting.
 Reflected XSS
Reflected XSS, also known as, Non–Persistence XSS or TYPE 1
XSS, is the case of attack that doesn't load with the vulnerable
web application but is originated by the victim loading the
offending URL. Now lets us see how the Reflected XSS takes
place.
Reflected XSS
 DEMO TIME 
 Stored XSS
Stored XSS is also known as Persistence XSS or TYPE 2 XSS.
Stored XSS occurs when a web application gathers input from a
user which might be malicious, and then stores that input in a
data storage for later use. The input, that is stored, is not
correctly filtered. As a consequence, the malicious data will
appear to be the part of the web site and runs within the user’s
browser under the privileges of the web application.
Stored XSS
 DEMO TIME 
 How to DETECT XSS
1. BLACK BOX TESTING
 Using web application scanner (Automated)
 Manually Testing
2. WHITE BOX TESTING
 Code analysis
 How to PREVENT XSS
1. Encode output, based on, input parameters
2. Filter input parameters for special characters
3. Filter output, based on, input parameters for special
characters
4. White list the Input
 Defense IN-DEAPTH (HttpOnly)
• Set the HTTPOnly flag on your session cookie and on any
custom cookie that you don’t want to be accessed by any
javascript.
• When you mark your cookie as HttpOnly, then it is not
accessible via javascript.
• In case after taking all the measures for XSS, if it still executes,
then HttpOnly flag minimizes the damage.
 References
• OWASP:- https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
• WASC:-
http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Script
ing
• Wikipedia:- http://en.wikipedia.org/wiki/Cross-site_scripting
• CERT Advisory:- http://www.cert.org/advisories/CA-2000-02.html

• You can also find this complete article on my blog

(http://securetechpoint.blogspot.in/) and also you can get this in
haking9 magazine http://hakin9.org/pentesting-with-android-exploiting-
software-0612/
 BE SAFE AND BE SECURE
•