This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Abstract- during the past decade, the Internet has become an indispensible part of our lives. Not only do we use the internet to search for information, but networking, blogging, user reviews, message boards, chat rooms, allowing users to post their opinions and experiences, have become expected system behaviour. The rapid development of web application, from static to interactive, in addition to tight deadlines forced on the developers to deliver application, resulted in the introduction of web security vulnerabilities. Web security vulnerabilities are a result of using readymade components and depending on their security or lack of security testing either to tight deadlines to deliver applications or to reduce cost. Web security vulnerabilities are vast in types and severities. Amongst these web vulnerabilities are cross site scripting, SQL injection, abuse of functionality and information leakage. This paper presents design and implementation of a tool to detect Cross Site Scripting (XSS). The tool; to the best of our knowledge, is the first tool allowing detection of both types of XSS attacks, both reflective and stored. The tool has been tested on 4 different applications containing both types of vulnerabilities. Results are promising, almost 80% of both types of XSS have been detected
Keywords: Web security vulnerabilities, Cross Site Scripting, SQL injection
Web applications have become an indispensible part of our lives through providing on-line services. Online services range from banking to governmental services. Associated with the development of on-line services, was the development of web applications. Static web applications are of minimal use to the average users. Users nowadays require interactive web applications; that would at minimal recognize them and accordingly load their previously saved preferences. In parallel with such development, web application security vulnerabilities also developed from least critical to most critical. Where least critical only resulted in crashing the web application and most critical resulted in stealing users' credentials and impersonating them
In reference to the Web Application Security Consortium, web application security vulnerabilities are classified into 6 classes .The classes are authentication, authorization, client side attacks, command execution, information disclosure and logical attacks. Each class contains a number of vulnerabilities. Amongst these vulnerabilities are: Cross Site Scripting (XSS), Information leakage, Content Spoofing, Insufficient Authorization, SQL injection, Predictable resource location, Cross Site Request Forgery, Session Fixation, HTTP Response splitting and Abuse of Functionality. The probability of existence of each web security vulnerably and its evolution or diminishing, is factored by the knowledge of web application developer and technology used and its evolution. Fig. 1 demonstrates the evolution of these vulnerabilities throughout the past 18 month as reported by White Hat Security.
Figure 1: Top 10 vulnerability classes (sorted by percentage likelihood)
As illustrated in Fig. 1, Cross site scripting has the highest percentage of occurrences amongst all listed web application security vulnerabilities. This is a result of its nature to propagate though networking, blogs, user reviews, message boards, chat rooms, Web mail and wikis. Moreover, Cross Site Scripting makes use of java scripts executed on user browsers and bypassing sand-boxing mechanisms. As a result, a malicious script is granted full access to all resources (e.g., authentication tokens and cookies) that belong to the trusted site
Web applications are not only becoming a part of our daily lives where we perform management of our "to do list", control our financial status, manage our contacts and our music and state our opinions and experience, but are also an important tool for managing businesses, both internally and externally. Businesses use web applications externally, as a source of advertising and trading and internally to manage employees, their wages and to monitor warehouses and profit. The list of functionalities provided by web applications is endless, so is the list and drawbacks of their in-competencies to meet them. An insecure web application means loss of identity on the personal level or loss of financial assets. On the business level, such insecure application means loss of data and loss of customer confidence. Whether the web application is used for personal or business purposes, its protection against web application vulnerabilities is of high importance, therefore the need for a tool that ensures our identity is preserved and that our customers are confident and secure is needed.
In this paper, we present the design and implementation of a XSS detection tool that detects both reflective and stored cross site scripting web applications security vulnerabilities. The tool is, to the best of our knowledge, the first tool to detect stored cross site scripting attacks.
The rest of this paper is organized as follows: Section II provides a background for web applications security vulnerabilities and an explanation of cross site scripting web application security vulnerability (XSS). In addition, section II explores related work for the detection of web application security vulnerabilities. Section III details the requirements, design and implementation of the Cross Site Scripting Detection Tool (XSS-DT). Section IV, illustrates the tool's performance evaluation experiments and analysis along with evaluation results. Finally section V, concludes the paper along with discussion of future work.
Background & Related work
A web security vulnerabilities as "A security vulnerability is a flaw in a product that makes it infeasible - even when using the product properly -to prevent an attacker from usurping privileges on the user's system, regulating its operation, compromising data on it, or assuming un-granted trust." . Web applications security vulnerabilities have evolved and have become very more complex to detect and fix. Amongst the reasons for emerging web applications security vulnerabilities are: Complexity of the application, code reuse and tight deadlines, forced on the developers to deliver applications. Web security vulnerabilities are a result of using readymade components and depending on their security or lack of security testing either to tight deadlines to deliver applications or to reduce cost
Cross Site Scripting
Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications that enables malicious attackers to inject a client-side script into web pages viewed by other users. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy .
Cross-Site Scripting (XSS) holes in popular web applications are being discovered at alarming rate. More than 73% of web sites are vulnerable to XSS holes. XSS attacks are easy to execute, but difficult to detect and prevent. The main cause is the high flexibility of HTML encoding schemes, offering the attacker many possibilities for circumventing server-side input filters that should prevent malicious scripts from being injected into trusted sites .
Cross-site scripting poses several application risks that include the following:
Session Hijacking: stealing user cookies which can then be used to impersonate them. This results in the hacker's access to user's data and privileges.
Redirecting the user to another website of their choosing. Maybe one that may be quite offensive, or one that attempts to install malware onto users' computers
Displaying alternate content on your own website
There are two main classes of XSS: Non-persistent and persistent.
Non-persistent Cross Site Scripting
Figure 2: The steps involved in a reflected XSS attack
Persistent Cross Site Scripting
Persistent, also known as, stored XSS vulnerabilities are common in applications that support interaction between end- users, or where administrative staff access user records and data within the same application. Such applications include, but are not limited to social networking, blogs, user reviews, message boards, chat rooms, Web mail, and wikis.
Unlike non-persistent XSS, persistent XSS needs 2 requests for it to take place. First, the attacker posts some crafted data containing malicious code that gets stored by the application. Succeeded by the former step, a victim views some web page containing the attacker's malicious code, which is at this moment is executed. For this reason, the vulnerability is also sometimes referred to as second-order cross-site scripting .
Fig. 3 illustrates the steps involved for persistent XSS to take place.
Figure 3: The steps involved in a stored XSS attack
Researchers in the past have proposed quite a few scanners, client side solutions, server side solutions and information flow based mechanisms to address XSS vulnerabilities. XSS tools are available for different phases of the software development life cycle (SDLC). In addition, these tools can be found as commercial or open source.
Scanners were implemented for both application and database. Application scanners are black-box tools and need not have access to the source code. Amongst these are SPI Dynamics WebInspect , Sanctum AppScan , OWASP WebScarab , Nikto  and Spike . As for database scanners, access to the database is a must. Examples for tools for database scanning are Application Security Inc. AppDetective  and MetaCortes .
Proxies such as Paros , Fiddler  and BURP  are available as open source tools. However they require good knowledge of hacking techniques .
Ismail et al. proposed and implemented a client side detection tool for XSS. The tool implemented a response change mode and a request change mode. The tool checks if the request contains special characters. A copy of the request is saved by the tool and the request is still forwarded to the server. The server's response is then examined if it contains special characters, if the characters match the saved request or does not contain any special characters; the response is forwarded to the user. If the response special characters do not match these of the saved request, the tool encodes the response and forwards it to the user after altering him .
Secubat, implemented by Stefan Kals, is a server side detection tool for XSS. Secubat crawls though the application and injects malicious codes in textboxes and analyses the server response. Results are saved for later retrieval of data. .
XSS Detection tool
The proposed XSS detection tool is based on ideas from the Secubat tool . The V-shaped SDLC was adopted for the implementation of the tool.
The V-shaped SDLC was implemented to ensure the each cycle of the development is tested and that the product meets the requirements from the early stages of its life cycle.
The requirements for the tool were gathered though brainstorming and by analysing currently available tools. Through out the development cycle, requirements were re-structured and developed.
The tool functional requirements are:
The tool's spider component shall crawl through the typed in URL to fetch and save the following, web controls
The tool shall
fill in the textboxes and text areas with the provided attack script
construct a query string using the filled in textboxes, fetched buttons and hidden variables
request the URL using the constructed query
The received response shall be crawled through
The hyperlinks shall be compared against the attack script
If any of the response's hyperlinks match the attack script, reflective XSS is recorded
Each of the response's hyperlinks shall be used to reconstruct a new request
The new request shall each be analysed
If any of the response's hyperlinks match the attack script, stored XSS is recorded
Number of detected stored XSS
Number of detected reflective XSS
Recommendations for fixes of the discovered XSS vulnerabilities
Through the analysis phase, sequence diagrams, class diagrams, use case and database ERD were developed to ensure correct understanding of both types of XSS and demonstrate the tool's architecture, main components and data base design.
The detection tool is composed of 6 components as demonstrated in Figure 4: Tool Components.
Figure 4: Tool Components
The 'HTML' component, the spider, will crawl through the provided URL and fetch the textboxes, buttons and a hidden variable web controls and saves the fetched components in arrays.
The 'Attack Manager' will use the arrays provided by the HTML component to inject the textboxes and text areas with the attack script provided
The 'Request' component will construct a query string using the injected textboxes and textures, fetched buttons and hidden variables and request the URL using the constructed query
The received response will be crawled though by aid of the HTML component and compared against the attack script, in case the response match the attack script, reflective XSS is recorded. This is an example of HTML code containing reflective XSS
<div id="ctl00_MC_MemberLogOn_LogonError" class="warning">Information for '<script>alert('minnie');</script>' not found (make sure you enter your email address, not your username)</div>
<table id="LogOnContainer" width="620px">
The 'HTML' component once again crawls though the response, to fetch the web controls, mentioned earlier, in addition to hyperlinks. Hyperlinks are then used by the 'Request' component to re-send requests, which are re-analysed and compared against the attach script. If any of the response's hyperlinks match the attack script, stored XSS is recorded. This is an example of HTML code containing stored XSS
<a href='http://xxx/2.html#<script src=http://xxx/a.js></script>'>a</a>
The cycle is repeated; till all hyperlinks, gathered though the crawling phase, are visited. Results are displayed to the user both as a summary, details and recommendations for fixes. Summary report gives the total number of discovered stored and reflective XSS attacks.
Figure 5 show the detection Pseudo code used by the tool to detect both types of XSS.
1 Initialize count of stored XSS to zero
2 Initialize count of reflective XSS to zero
3 Input URL required for testing
4 Input attack script (ex. <script>alert ("XSS")<s/cript>)
5 While (! End of application)
6 Crawl though URL
7 Identify control type (textbox, buttons and hidden variables)
8 Add to control arrays
9 Inject controls with attack script
10XSS-DT constructs request
11 XSS-DT sends request
12 XSS-DT receives response
13 While (! End of application)
14 Crawl though URL
15 Check if (attack script exists)
16 Increment reflective XSS
17 While (! End of application)
18 Crawl though URL
19 Identify control type (textbox, buttons and hidden variables, href)
20 Add to control arrays
21 While (more href)
22 XSS-DT constructs new URL using href
23 XSS-DT constructs request
24 XSS-DT sends request
25 XSS-DT receives response
26 Crawl though URL
27 Check if (attack script exists)
28 Increment stored XSS
29 Print results
Figure 5: Pseudo code for detecting XSS
Figure 6 is a sequence diagram detailing the proposed and implemented detection mechanism
Figure 6: Detection Sequence for both stored and reflective XSS
The database stores the summary, detailed and recommendation reports for later retrieval.
The tool's architecture and database design were designed to allow extensibility, where new web security vulnerabilities could be added with minimal effort, reusing all classes without the need to reconstruct any of them.
Performance Evaluation and Analysis
The tool was implemented as a Windows Forms .NET application in C# using Microsoft's Visual Studio.NET 2008 and Microsoft SQL Server 2000 Database Management System (DBMS) was used to store the data.
The tool passed through 3 phases of testing as listed in Table 1.
simple developed web application
real social networking, blogs, user reviews, message boards, chat rooms, Web mail, and wikis
Table 1: Testing phases
The first phase included testing the tool on a simple developed web application. The developed application was both vulnerable to persistent and non-persistent XSS.
The second phase was to test the tool on benchmarks, having both vulnerabilities and at the same accredited by many. OWASP WebGoat  and WackoPicko  were chosen. The former is a J2EE vulnerable application maintained. WebGoat provides more than 10 lessons for developers to learn about web application vulnerabilities in general not just only XSS. The latter is an application developed specifically to test different scanners.
The third and final step was to test the tool on real social networking, blogs, user reviews, message boards, chat rooms, Web mail, and wikis.
PHP-Nuke is a content management and portal solution featuring web-based administration, surveys, customizable blocks, modules and themes with multi-language support
PHP-Fusiion is a content management developed in PHP/mySQL
WordPress is a personal publishing platform with a focus on aesthetics, web standards, and usability.
Drupal is an official homepage of the open source content management system. Offers documentation and the source for download and hosts a developers and community
Handles the administration of one or more MySQL servers over the web. Written in PHP
phpBB is free and open source forum software that is easy to use, powerful, and highly customisable. Our community offers extensive support to end users
Table 2: Test applications
The experimental results show that the proposed system provides the expected functionality, for detecting both stored and reflective XSS. The results are very promising; almost 50% of both types of XSS have been detected. In addition, the results have been compared to a previously developed tool Secubat. Results illustrate that XSS-DT was capable of detecting stored XSS which Secubat did not detect.
Stored Cross Site Scripting Results
Table 2 lists the results of detecting stored XSS. As illustrated by numbers the XSS_DT was able to detect stored cross site scripting while SecuBat tool was unable to.
# of vulnerabilities existing in application
Detected by tool
Detected by SecuBat
Table 3: Stored XSS Results
Reflective Cross Site Scripting Results
Table 3 lists the results of detecting reflective XSS.
# of vuln. in application
Detected by tool
Detected by secubat
Table 4: Reflective XSS Results
Conclusions and future work
The paper presented a detection mechanism for both stored and reflective XSS. The paper started by giving an introduction and backgrounds the 2 types of XSS. The requirements for the detection tool were then listed. The analysis of the requirements was then introduced based on the requirements. The design meeting the previous analysis phase was then explained. Finally the implementation of the detection tool was given and results were plotted.
In the future, the tool's performance is to be measured and improved though threading, if needed. A recording and playback component can be also added to the system. Other security vulnerabilities could be added to the tool ex. SQL injection.