Exploitation Of Xss Vulnerability Tool Computer Science Essay

Published Date: 02 Nov 2017

1Madhav Khosla, 2Megha Korgaonkar, 3Reetika Kohli, 4Uma Sahu

Don Bosco Institute of technology, Kurla, Mumbai

[email protected],[email protected],

[email protected],

Abstract— Cross-site scripting (XSS) is a web

Application attack in which scripting code is injected into the application’s output that is then sent to a user’s web browser which is then executed and used to transfer sensitive data to a third party (i.e., the attacker). With the introduction of new standards like HTML5, these attacks became more and more powerful. As these attacks are becoming very popular we made an attempt to identify the possible attacks in the near future. With making an attack we also made an attempt to design a new enhanced defence addressing some of the attacks. We have tried to implement our design as a Mozilla Firefox Extension.

Introduction

As the Internet is growing rapidly, the security threats it poses have also been increased. There are many attacks like cross site scripting, cross site request forgery, click jacking, SQL injection, command injection etc.

A. CROSS SITE SCRIPTING

In Cross site scripting an attacker injects client-side script into HTML pages viewed by other users. Suppose that a web application is displaying one user's comments to the other user, if a malicious user injects JavaScript into his comments, when another benign user visits these comments the JavaScript will be executed in victim's browser. Almost 80% of websites are cross site scripting vulnerable as of October 2010.

B. TYPES OF CROSS SITE SCRIPTING

There are 3 types of cross site scripting

Reflected cross site scripting - In this type of cross site scripting, content received by the server

from the user through the parameters is reflected back to the user. for example: in search sites search key words could be reflected back. For this types of XSS, attacker has to craft a URL with the parameters containing malicious script and send it to the victim. When victim clicks on the link, the malicious content will be reflected back to the user. In the second method, called reflected XSS, the attack script is not persistently stored, but, instead, it is immediately "reflected" back to the user. For instance, consider a search form that includes the search query into the page with the results, but without filtering the query for scripting code. This vulnerability can be exploited, for example, by sending to the

victim an email with a specially-crafted link that points to the

search form and that contains the malicious JavaScript code.

By tricking the victim into clicking this link, the search form

is submitted with the JavaScript code as the query string, and

the attack script is immediately sent back (reflected) to the

victim, as part of the web page with the results.

Persistent cross site scripting - In this type of cross site scripting the content injected by a user

(for eg: comments ) will be stored on server and will be displayed to another user when he visits

the page.

DOM based cross site scripting - In this type of cross site scripting server would not inject

content, but a client side component dynamically injects content into the page from the user supplied

content into the page.

C. EFFECTS OF CROSS SITE SCRIPTING

A cross-site scripting vulnerability can be used by attackers to bypass browser sand boxing for JavaScript. If an attacker injects code into a page which is in a particular domain, he can access all the sensitive information belonging to that domain. For example if an attacker can inject a script

into a page from mail.google.com he can access all the sensitive information (Example cookie,history,form

values) of all pages from mail.google.com, google.com. Bypassing this policy can result in

By obtaining cookies, session hijacking attacks can be performed.

As the script have the access to the DOM, An attacker can modify the DOM and do a phishing

which can evade most of the anti-phishing defence currently available .

Cross site scripting can be used to install key loggers on the vulnerable domain.

Cross site scripting can be used to spread web worms(eg: samy worm)

This attack can be used to circumvent the defences for attacks like cross site request forgery.

Along with the above mentioned attacks there are many more next generation attacks coming up

because of advances in technology . Hence there is a strong need for defending these attacks. The defences

can be employed at either server, client or we can use a combined approach. Server side approach and

combined approaches failed in most of cases since web developers are not security aware.

Approach

Attacks have become more sophisticated with the increased

use of new technologies. For defender to win the race between

the attacker and defender, there is an immense need to

anticipate the next generation attacks by understanding the

earlier attacks, so that they can be defended before any real

damage. This motivates us to investigate for the possible next

generation attacks and alert the defenders about these kind of

attacks. Defending against any attack needs a thorough understanding of the underlying vulnerabilities. For this

purpose, vulnerabilities are identified systematically and a detailed taxonomy of the vulnerabilities is created. A web application with these vulnerabilities and without any defence mechanisms has been created. A single vulnerability could be exploited in many possible ways, ideally a client should defend all these types of exploits. For this purpose, different types of exploits to attack these vulnerabilities

have been designed. These exploits have been tested on 3 popularly used recent versions of browsers to

evaluate their ability to defend different attacks and identify the limitations of the browsers. Both the browsers we have considered(IE and Google-chrome) have their limitations in detecting cross site scripting attacks. We have designed a new defence addressing some of the limitations that are identified. Our defence tries to defend by identifying the special characters(characters that are part of language constructs) in the parameters that are being sent out to identify the suspicious parameters. When the response is received suspicious parameters are matched against response to identify the reaction. Once the reaction is identified they will be encoded according to their context in document(body or script). We have implemented our defence as a Mozilla extension. We have thoroughly evaluated our defence

in multiple ways for both false positives and false negatives. For identifying false negatives we have tested breadth wise (that is different categories of vulnerabilities), depth wise(multiple exploits for one kind of vulnerability) and we have considered some of the real world vulnerabilities as well to correlate the behaviour with the servers behaviours. For verifying false positives we have identified the reacting

forms in TOP1000 sites by crawling up to a depth of 50.

We have accessed these form action URLs with parameter values as strings containing special characters with our defence being employed, to get an estimation of maximum number of possible false positives. We have also analysed our normal browsing data to test for false positives and our results shows that false positive rate is less than 0.02.