“Cross Site Scripting (XSS) attack in web application and its mitigation”


Security is a broad topic area and the threats are constantly evolving. Security encompasses more than just writing secure code, but also items like the Configuration and setup of the servers and network, and practices and procedures for handling sensitive data. Cross-site Scripting (XSS) refers to client-side code injection attack wherein an attacker can execute malicious scripts into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application makes use of un-validated or unencoded user input within the output it generates. By leveraging XSS, an attacker does not target a victim directly. Instead, an attacker would exploit vulnerability within a website or web application that the victim––would visit, essentially using the vulnerable website as a vehicle to deliver malicious script to the victim’s browser. While XSS can be taken advantage of within VBScript, ActiveX and flash unquestionably, the most widely abused is JavaScript–primarily because JavaScript is fundamental to most browsing experiences.


Cross-site scripting attacks use known vulnerabilities in web-based applications, their servers, or the plug-in systems on which they rely. Exploiting one of these, attackers fold malicious content into the content being delivered from the compromised site. When the resulting combined content arrives at the client-side web browser it has all been delivered from the trusted source, and thus operates under the permissions granted to that system. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, to session cookies, and to a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are a case of code injection.


There are currently three major categories of cross-site scripting. Others may be discovered in the future, however, so don’t think this sort of misuse of Web page vulnerability is necessarily limited to these three types.

  1. Non-persistent/Reflected XSS Attack
  2. Persistent/Stored XSS attack
  3. DOM based XSS attack
  4. Impact of XSS attack

4.1 Cookie stealing and account hijacking

4.2 Misinformation

4.3 Denial of Service

4.4 Browser exploitation


Next, we describe the methodology for our experiments to detect DOM XSS vulnerabilities on the Internet. In we describe how we crawled websites and which web pages we visited. In we discuss the specifics of the taint-tracking engine we developed. In, we describe how we confirmed vulnerabilities. Finally, we

Detail the methodology for testing static-analysis tools

  1. Crawling for DOM XSS vulnerabilities
  2. Dynamic taint analysis
  3. Attack confirmation
  4. Static analysis

Method A: injection at end of URL

Observed URL:

example.url.com/path?param=test&a=b Generated injection

URL: example.url.com/path?param=test&a=b#

Method B: injection into parameter Observed URL: example.url.com/path?param=test&a=b

Observed eval-ed string: var a = ‘test’; Observed taint location: The 9th through 13th bytes of the string—starting with the first ‘t’ in test and ending with the last ‘t’ in test. Generated injection URL: example.url.com/path?a=b#&param=INJECT


We used the taint-tracking and crawling methodology described in to collect a dataset of tainted flows. We visited 44,722 web pages, which had in total 319,481 frames. One would expect that trying to visit five subpages on each domain; we would have visited 60,000 web pages: 10,000 top level pages and 50,000 subpages. However, we skipped loading

1,761 web pages due to robots.txt directives; and we were unable to load 4,094 web pages after three attempts due to timeouts, 462 because Chromium would not load the page (most often due to SSL warnings), and 26 because Chromium

Crashed when rendering them. Some of the pages unable to be loaded were top-level pages; in that case we also did not visit

Other pages on that domain.

We describe how we detected DOM XSS vulnerabilities using our dynamic analyses  we use the results from our dynamic analysis to evaluate different static-analysis tools for detecting DOM

XSS vulnerabilities. Final, we describe the

Qualitative trends that we observed from manually analyzing a sample of our dataset.

Leave a comment

Your email address will not be published. Required fields are marked *