1. Introduction
Ensuring information security (IS) in computing systems is a priority for organisations that use algorithms to collect, process, store and transmit information. However, with the widespread use of the internet, many threats to IS have emerged. Most web applications used over the previous decade were static and lacked interactive user interfaces and thereby had no exploitable vulnerabilities [
1,
2]. As a result, many developers ignored web application security issues at the time. Whilst a large number of dynamic websites that utilise modern technologies to connect users to web applications and enhance their interactions with web resources (e.g., bulletin boards and feedback forms) have been introduced in recent years, these innovations have vulnerabilities that allow intruders to perform computer attacks, such as SQL-injection and cross-site scripting (XSS) [
3]. With the help of injected code, an intruder can gain unauthorised access to user data, which could allow them to impersonate these users, perform illegal actions on the local computers of users and the network equipment of their companies or change the configurations of their network and software. The lack of proper measures for ensuring IS has resulted in the emergence of computer attacks linked to malicious code execution [
4].
According to the Open Web Application Security Project (OWASP), cross-site programming is one of the most common types of computer attacks [
5]. Around 65% of websites are exposed to XSS vulnerabilities detected in current web applications [
6], as shown in
Figure 1.
As shown in
Figure 1, it is clear that information leakage is the second biggest threat, with 46% of websites exposed to this type of cyber vulnerability.
Recently, poorly developed software programs have been identified as safety threats. The number of viruses to which a system is potentially exposed is directly associated with the size and complexity of the established net packages and servers. Most multifaceted applications have both extensive loopholes and a few already identified weaknesses. In addition, net servers are intrinsically multifaceted applications. Websites are also multifaceted and even intentionally request extra data from users. Cross-site web page scripting (XSS) is one of the riskiest and most-exploited assaults in current times. Almost 65% of websites have been identified to have one or more of the XSS vulnerabilities listed in current net packages.
Cross-site attacks, where users inject payloads (malicious code) in the customer section of a website, are the most common network attacks via the web. Weak spots found in poorly encrypted websites are exploited by attackers, using the victim’s browser to send malicious text from vulnerable sites. The types of attacks exploiting XSS vulnerabilities are presented in the next section, followed by examples of XSS vulnerability detection software in
Section 3. Then, the evaluation results are discussed in
Section 4. Finally the conclusion is presented in
Section 5.
2. Types of Attacks Exploiting XSS Vulnerabilities
XSS is a computer attack that involves injecting malicious code into the webpage parameters sent to a web browser. This computer attack is similar to SQL-injection [
7] and can be used in various ways [
8]. XSS attacks can be classified according to the vector and the method of influence, as shown in
Figure 2.
Based on the XSS impact vector, an XSS attack can be classified as follows:
Active XSS, which does not require additional actions on part of the user in terms of the functionality of web applications.
Passive XSS, which is triggered when a user performs a certain action, such as clicking or hovering the cursor.
Reflected XSS.
Stored XSS.
XSS based on the document object model (DOM).
2.1. Reflected XSS
Reflected XSS attacks are the most common type of XSS attack, and the vulnerability exploited by this attack is easy to detect. In a reflected XSS attack, the code is sent to the server and returned to the user within a single HTTP request. The XSS using a reflected XSS vulnerability follows a complex process wherein the malicious code is injected into a URL, this URL is sent to the user, and the user must click on this URL to run the malicious code.
However, such complexity does not present an obstacle for attackers. A basic reflected XSS attack does not aim to steal confidential information. When a user visits a website with a reflected XSS vulnerability, a warning window is displayed after executing the script code. A link to a webpage with a basic reflected XSS vulnerability resembles the following:
http://site.com/<script>alert(“XSScompletedsuccessfully”)</script>). An advanced internet user would find this link strange and would refuse to proceed to the directed webpage. One method for hiding such a malicious link is RFC 1738 encoding [
9]. In the following code snippet, after encoding a malicious URL, the script code becomes unrecognisable:
Attackers combine a reflected XSS vulnerability with other types of attacks to boost the effect of exploiting such a vulnerability. This approach has resulted in a new type of computer attack called clickjacking, which tricks a person into clicking a link that is invisible or disguised as some other element [
10,
11]. Clickjacking has the following features:
Link theft occurs when a user clicks on a malicious link or button generated by an attacker.
Clickjacking does not need injected scripts, hence facilitating the implementation of the attack.
This type of attack is based on dynamic HTML.
This attack is easy to perform.
Clickjacking itself has led to another type of computer attack that combines JavaScript (JS) with HTML Iframe tags. IS specialists call this computer attack cross-frame scripting (XFS), and it loads legitimate pages to steal user data. An XFS attack is only successful when combined with social engineering. Consider a scenario where the attacker, by using social engineering methods, convinces a user to go to a specially crafted page. After visiting this page, malicious JS codes and Iframe tags are loaded into the web browser of the user. When a user enters his/her credentials in an Iframe pointing to a legitimate site, the malicious JS code steals his/her keystrokes.
Redirection XSS is another type of XSS attack that exploits the reflected XSS vulnerability of web applications. In this type of attack, malicious code is downloaded from an untrusted source and injected into various web application scripts.
In a redirection XSS attack, data from an unreliable source enter a web resource in the form of web requests. The received data are then wedged into the dynamic content of the web application and sent to the user without checking for malicious codes.
The malicious content sent to the web browser of a user often takes the form of JS code, but may also include HTML, Flash or any other code that can be processed by a web browser. Computer attacks using stored XSS vulnerabilities are more dangerous than those that use reflected XSS vulnerabilities given that the former can be used for a long time.
2.2. Stored XSS Attack
Stored XSS attacks are mainly used to steal session information (e.g., cookies), redirect users to a malicious web resource or allow attackers to perform malicious operations on the PC of the user. Two of the most dangerous computer attacks that exploit a stored XSS vulnerability in a web application are cookie theft and Trojans.
Cookies are small pieces of data that are stored in the web browser of users and include user data and other information that may be utilised to recognise a user whenever s/he accesses a web application. Cookies are generated on the web server side, sent to the web browser of users and stored in the local storage of this browser. The next time a user accesses this web application, the saved cookies will be sent to his/her web server to recognise the user and to grant the attacker access to certain web resources based on the information stored in these cookies [
12,
13].
Attackers may also use an XSS vulnerability to trick users into downloading a Trojan horse for carrying out a long-term computer attack. IS specialists call this computer attack an XSS-based Trojan horse [
14]. To carry out this type of attack, the attacker needs the user to download a Trojan programme by using a stored XSS vulnerability in his/her web application. Malicious code is injected into the area of the web application with a stored XSS vulnerability to download a Trojan programme. Anyone who visits this page will automatically follow a link with a malicious JS code, which will be processed by their browsers and downloaded onto their computers. In this case, XSS-based Trojan horse attacks generally go unnoticed because this type of attack users Iframe to create a child window whose size is set to 0.
2.3. XSS Attack Based on DOM
By using a JS script, an XSS attack based on DOM exploits an XSS vulnerability in the DOM that occurs on the side of the user during data processing. As implied in its name, this type of XSS attack is implemented through DOM, a platform- and language-unbiased programming interface that gives applications and scripts access to the contents of HTML and XML documents and modifies their content, shape and execution [
15]. With incorrect filtering, the DOM of the attacked site can be modified, and the malicious JS code can be executed in the attacked site.
XSS vulnerabilities can be detected using several methods, including BeEF, Xenotix-XSS, Acunetix, XSpider-MAX-Patrol, Nemesida-Scanner and Wapiti.
XSS attacks based on DOM send a trusted-server-managed script to the user of a web application. Take, for example, a JS code that checks the completeness of a form before being sent out to the server. The script processes the entered data and inserts them back to the webpage (e.g., via dynamic HTML), hence allowing attackers to ‘wedge’ a malicious code into a JS script.
In summary, existing information security tools provide a variety of algorithms and programs that can block various information security threats. Most vulnerability tools are heavy and provide redundant features that can slow computer systems and increase resource utilization. Further, there are downsides to simple solutions that are simply “tuned” to find XSS vulnerabilities. The weakness of XSS trackers is related to its ability to write web applications. Most web applications license web resources to increase user rights. This means that allowed users can more easily access the features of web resources than non-privileged users.
3. XSS Vulnerabilities Detection Software
Modern data protection software and equipment utilises a wide range of algorithms and programmes to forestall data security threats [
16]. However, most of this software and equipment has cumbersome operation and redundant performance that can slow the devices of users and increase their resource consumption. Meanwhile, solutions that can easily detect XSS vulnerabilities have other drawbacks associated with the peculiarities of constructing web applications. Specifically, most web applications authorise internet resources to expand consumer privileges; that is, authorised users are given more access to the functionalities of a web resource compared with unauthorised users.
The existing software for detecting XSS vulnerabilities, such as the Online Web Security Scanner, search for these vulnerabilities only in the open parts of websites that do not require access authorisation [
17,
18,
19,
20,
21]. Such a drawback is significant considering that XSS vulnerabilities may be located in an unsearchable part of a web resource.
Therefore, applications that search for the XSS vulnerabilities of a web application are urgently needed. To fulfil such demand, this paper designed a programme based on the symmetrical utility of most high-quality algorithms for discovering XSS vulnerabilities. The Delphi programming language was used during programme development. The proposed programme implements the following functions:
Detection of all types of XSS vulnerabilities (including reflected, stored and DOM-based XSS);
Pre-authorisation in web applications and cookie storage;
Compilation of internal URLs in a web application;
Creating reports on the detected vulnerabilities; and
Recommending the necessary actions for the detected vulnerabilities.
Figure 3 presents the search algorithm used for reflected XSS vulnerabilities.
Another possibility is an attack on insufficiently processed data from the HTTP response. Malicious code in the case of reflected XSS is only embedded in the HTTP response, not stored in the application. In this case, it may occur that malicious code to run it is included in the response.
Given that reflected XSS vulnerabilities are only observed when submitting forms, the above algorithm triggers the submission of these forms using the POST method, which involves inserting values in the sent elements and receiving a response in the form of an HTML message. The incoming message is then analysed for vulnerabilities as follows:
If the incoming JS code sets the value stored in the document object model to a true value (document. vulnerable = true), then the page is marked as containing a potential threat of the corresponding type; otherwise, the page is marked as safe and is not added to the final list of vulnerabilities.
Figure 4 presents the proposed search algorithm for XSS vulnerabilities based on DOM.
During execution of the proposed search algorithm for XSS vulnerabilities based on DOM, the algorithm analyses the current page code including the hidden scripts in HTML tags. Then, the software searches this information for scripts that are used for calls to DOM methods. Calls to DOM methods are similar to the following:
Figure 5 shows the proposed algorithm used to search for stored XSS vulnerabilities. Stored XSS occurs when a web application receives data from an untrusted source and then includes this data in its later HTTP responses. These malicious data or scripts can be placed, for example, in a comment next to a post, in a message forum, in a visitor’s log or in other places that are visible to other visitors. This algorithm has unique characteristics given that, unlike reflected XSS vulnerabilities, stored XSS vulnerabilities are the result of saving scripts in a database. This operation must be carried out using a preliminary POST request to prevent malicious codes from modifying the database. This algorithm is similar to that used for detecting reflected XSS vulnerabilities, except the former requires the user to submit the form and wait for a response from the server.
After the script is executed, the form and XSS injection are stored in a special structure along with other information pertaining to the detected vulnerability. After the script is executed, the search is terminated because when the form is submitted, the script located in the web application database will be executed. Therefore, the scan must be performed again after the vulnerability is fixed.
Figure 6 presents the algorithm of the developed programme.
In summary, as a very urgent mission, software that searches for XSS vulnerabilities by analysing the full map of the web page, including the hidden scripts, is developed. The proposed software is based on consistent application of the most effective algorithms to detect various types of XSS vulnerabilities, as presented in this section.
4. Evaluation Results
The assessment criteria were based on standards proposed by software security organizations and researchers to help develop the basic tools used to assess web browser vulnerabilities. Open Web Application Security Outlook (OWASP) provides an up-to-date assessment of ten critical security threats that threaten internet application security today.
The evaluation experiment of cross-site scripting (XSS) attacks is based on an XSS impact vector and includes reflected, stored and DOM-based XSS.
The measurements for this experiment are vulnerability detection rate based on the number of detected vulnerabilities, average time spent finding vulnerabilities and total time spent in the search process. Since all the scanners in our study were eligible for PCI compliance, they were mandated to test for each vulnerability category of the Top Ten Open Web Application Security Project (OWASP). We also examined each scanner’s scan profile customization features to get a better idea of their target vulnerability categories.
This study focuses on three types of cross-site scripts: XSS-type-1, XSS-type-2 and XSS-type-3. XSS-type-1 is comprised of samples of reflected-XSS scripts, executed via a <script> tag. XSS-type-2 is comprised of stored-XSS vulnerabilities, where untrusted user input is written to a database and then executes a script when read from the database. XSS-type-3 includes hidden scripts in HTML tags that make up reflected and stored XSS using non-standard tags and keywords, such as <style> and prompt().
In this study, data were entered into the programme configuration section, if necessary. This was also searched for specific XSS vulnerabilities to save time. After the search was completed and if records in the internal structure matched the detected threats and their descriptions, a report on these vulnerabilities was generated.
Table 1 presents an example of the generated report.
This report provides web developers with complete information about the web application being tested and proposes some recommendations for fixing each detected vulnerability, thereby greatly simplifying their work. The issuance of recommendations is considered an advantage of the developed programme over existing vulnerability-detection software.
Using the advanced software program to discover XSS vulnerabilities will be a boon to the effectiveness of shielding Web applications. In practice, the advanced application simplifies the checking of internet applications. Due to the capability of the report, technology with tips for the removal of detected XSS vulnerabilities makes it feasible to apply this system by customers who do not understand the fundamentals of records security.
To evaluate the developed programme, its main characteristics were compared with those of similar solutions, namely, BeEF, Xenotix-XSS, Acunetix, XSpider-MAX-Patrol, Nemesida-Scanner and Wapiti. The comparison results are presented in
Table 2.
The developed program and the aforementioned solutions were tested on the Open Web Application Security Project (OWASP) Juice Shop, which is an internet resource that was specifically designed for training and testing software for detecting XSS vulnerabilities.
Juice Shop is a web application with a huge amount of vulnerabilities and is actively supported by the worldwide information security community. The OWASP consortium also owns the project and distributes it under free licenses. It can be used in security training, demos, CTF competitions and security testing.
Juice Shop includes vulnerabilities from the OWASP TOP 10 list, as well as many other vulnerabilities found in real applications.
The developed programmes Acunetix and XSpider demonstrated the best performance in detecting vulnerabilities, as shown in
Figure 7. Despite detecting the same number of vulnerabilities as Acunetix and XSpider, the developed programme spent 44% and 20% less time in detection compared with Acunetix and XSpider, respectively, as shown in
Figure 8.
The developed programme also spent 25% and 20% less time searching compared with Acunetix and XSpider, respectively, as shown in
Figure 9.
The above results highlight the following advantages of the developed programme:
searches for XSS in closed parts of web resources;
finds more XSS vulnerabilities compared with similar programmes;
spends the least amount of time in detecting XSS vulnerabilities; and
proposes recommendations for eliminating the detected vulnerabilities.
Furthermore, accuracy, precision and recall were measured. More specifically, accuracy provides the percentage of the three types of threats that were correctly detected. Precision determines the fraction of web pages correctly classified as XSS over all web pages classified as XSS vulnerabilities. Recall is the fraction of web pages correctly classified as XSS vulnerabilities over all web pages of XSS vulnerabilities. The proposed system has 99.47% accuracy, 100% precision, and 81% recall.
However, this work is limited to only one type of injection attack: XSS. Injection attacks are included in the OWASP Top 10 list, especially SQLi (SQL injection) and XSS, which are not only very widespread but also very dangerous, especially in older applications.
Future work will focus on others injection attacks and different injection detection tools that can be used to better understand vulnerabilities. Other injection attacks include code injection, and NoSQL.