Keywords

1 Introduction

In March 2017, Google reported a thirty-two percent increase in the number of hacked websites [7]. Unsurprisingly, website breaches have become an everyday occurrence that they don’t make the news anymore. The leading cause of infections were vulnerabilities found in websites extensions, plugins, modules, and significantly, from Cross-site scripting (XSS) attacks [8]. XSS vulnerability has a tremendous impact on web applications security [6]. To perform an XSS attack, a malicious user only needs a web browser. XSS vulnerability is mostly found on parameter-based components of websites, such as the search bar or on the login page [13]. In cross-site scripting attack a malicious user infects a victim computer’s browser by injecting malicious JavaScript on a trusted host. Most websites would run JavaScript easily on the server side if the website did not have any protection against malicious injection of codes [13].

The fact that cross-site scripting attacks can be launched from any web browser, present a security challenge. XSS specifically targets webpages that accept unlimited input from users. Typically, XSS occurs when an adversary inserts some malicious scripts or payload in a website. Consequently, when a victim visits this infected website, the injected malicious JavaScript is triggered and the security of the user and the website become compromised [6]. Cross-site scripting attacks are not limited only to JavaScript. They extend to other programming languages such as .NET, PHP, JAVA amongst other scripting and web programming languages as well.

Moreover, the rapid proliferation of the Internet of Things in our life may attract even more XSS attacks [11]. For instance, many devices connect to the Web of Things using existing open standards [3]. They typically communicate and exchange data via open protocols such as those that are based on JSON data structures and JavaScript. The fact that the IoT is connecting more insecure devices to the Internet risk exposing businesses spanning from the health industry [4] to homes to various security threats including XSS. Therefore, network and cyber security solutions must address a new range of security vulnerability such as those reported in [1, 9] and [5] including malicious cross-site scripting attacks. Thus, there is an urgent need for comprehensive and robust security solutions to defend against XSS attacks.

Henceforth, this paper reviews some of the traditional cross-site attack techniques. The research then moves to propose a set of guidelines, which aim at improving the security of Web applications. The rest of this paper is structured as follows: Sect. 2 describes cross site scripting attack methods. It specifically discusses the three most common type of XSS attacks. Section 3 presents guidelines and recommendations that can contribute towards the prevention of XSS attacks. Concluding remarks are presented in Sect. 4.

2 Cross-Site Scripting Attack

XSS attacks can be divided into three main genres: Reflected XSS, Stored XSS, and DOM based XSS [2]. Amongst these three attacks, Stored and DOM based XSS attacks are considered very critical for the security of web applications [2].

2.1 Reflected XSS

Reflected XSS attacks, also known as non-persistent attacks, occur when malicious JavaScript codes are transferred from the infected website to the victim’s browser. The malicious codes are usually triggered because of a rogue incoming request. Generally, in Reflected XSS a malicious user inputs their malicious JavaScript payload by exploiting the search functionality of a website or anywhere on the main page of the website that accepts users’ input [9]. Reflected XSS is not stored anywhere parentally. Instead, it executes on the browser’s victim. The attack works by imputing malicious JavaScript payload on the client side. A Reflected XSS attack can be constructed as follows: A malicious user crafts an URL containing malicious JavaScript payload such as: https://www.bank.com/?search=” script>alert(1)</script>

In the above URL, the attacker inserted a malicious JavaScript code i.e. "<script>alert(1)</script>" by exploiting the search feature of the website. If the web application did not have any protection against cross-site scripting, then the inserted script will be validated by the webserver and a result could be returned or executed on the client side. A typical Reflected XSS attack is shown in Figs. 1 and 2. Figure 2 illustrates how an attacker injects some simple malicious code on the trusted server. Once this code is executed (step 2 and 3 of Fig. 2), the attacker can gain access to some of the victim’s sensitive information such as the information stored in the victim browser’s cookie.

Fig. 1.
figure 1

Reflected cross site scripting infecting a victim browser

Full size image

2.2 Stored XSS

Stored XSS is also known as HTML code injection on the client side. In Stored XSS attacks, an attacker input some malicious script in any form input field such as in a textbox that can be used when creating a user profile [12]. This is the most straightforward and basic Stored XSS attack used to store malicious code on a webserver. Obviously, this sort of attacks can be easily defended against using server-side validation. Other Stored XSS attacks can be employed by an attacker to construct a phishing attack. The attack starts when the attacker inserts some malicious HTML code inside a webpage. The injected code can be used to redirect the user to a fake website where the finishing attack can occur.

2.3 DOM Base XSS

DOM based XSS attacks are also known as exposed injection attack in web applications. DOM based XSS can infect the server, which is harmful to the web portal. In this type of attacks, an attacker tries to insert malicious script into the loading URL such as <imgsrc="abc"onerror="alert(1)"> in the following example:

https://bank.com/#<imgsrc=“abc”onerror=“alert(1)”>

Most websites use # key for page redirection or to call embedded pages from the source code. Therefore, an attacker can exploit this vulnerability by inserting # key followed by a malicious script. This will trick the server into thinking that the client is calling for a specific page. The server then proceeds in allowing the malicious payload to run leading to its injection in the source code of the webpage. Next, the server tries to find <img> name tag in the page; which is of course malicious and does not exist. The server then generates an error as a result of not finding the image. Consequently, when the server returns an error, the injected JavaScript onerror= "alert(1)" will be executed in the form of a popup [8].

In Fig. 3, there is some special case in which the server does not identify the malicious payload in the URL. This is because the malicious user used fragmentation of the URL. Fragmentation of a URL is done using # key which is used to insert malicious script. In this way, the server will just check # key and think it is asking for some specific page on the website. As a result, the server will be tricked into allowing the items after # key to be injected. It then becomes possible to do some server-side injections. It means that the OS command injection can be done or some other HTML injection which is also possible if the website did not have proper URL.

Fig. 2.
figure 2

Reflected XSS attack

Full size image
Fig. 3.
figure 3

DOM based XSS Attack example

Full size image
Fig. 4.
figure 4

URL DOM base XSS Attack

Full size image

Several prevention techniques are available online for cross site scripting, but many protections prove totally wrong to prevent cross site scripting on web application. This is because these prevention techniques were not tested or evaluated properly. For instance, many researchers proposed to prevent cross site scripting attacks by adding some filtration on the website such as, escape some special characters and HTML blacklisted words from the input. However, in practice, this can be easily compromised by attackers. An attacker can put a malicious script in string encoding format. Therefore, the use of basic encryption will not be enough to protect the website against cross site scripting (Fig. 4).

Fig. 5.
figure 5

XSS attack sequence diagram

Full size image

Figure 5 illustrates how cross site scripting attack happens on a web browser. The solution proposed in [12] relies solely on encryption, which we believe is not enough. The authors suggested that “an application needs to ensure that all variable output in a page is encoded before being returned to the end user. Encoding variable output substitutes HTML mark-up with alternate representations called entities. The browser displays the entities but does not run them. For example, <script> gets converted to &lt;script&gt;. When a web browser encounters the entities, they will be converted back to HTML and printed but they will not be run. For example, if an attacker injects<script>alert("you are attacked")</script> into a variable field of a server’s web page, the server will, using this strategy, return&lt;script&gt;alert("you are attacked")&lt;/script&gt;. When the web browser downloads the encoded script, it will convert the encoded script back to <script>alert("you are attacked")</script> and display the script as part of the web page but the browser will not run the script [10].”

While the above quoted solution provides a way to reduce the risk of corss-site scripting, it is does not prevent this sort of attacks. This is because encryption filtration is not capable to prevent cross site scripting. Consider for example the case when an attacker put some malicious script without any special symbol characters in the inputs. This will result in bypassing the protection measures proposed in [12]. To fill this gap, we propose a secure framework that can be used to prevent cross site scripting in web applications.

3 Preventing Cross-Site Scripting

To prevent cross-site scripting attacks, a web developer must perform many testing criteria as well adding some prevention code or functionality in their web application. Typically, most Web developers use encoding along with basic client-side validation. However, these measures may not be strong enough to prevent cross-site scripting attacks. Therefore, to prevent XSS attacks, we propose the followings security guidelines:

  1. 1.

    Define restricted locations: never allow untrusted data to execute on web applications except in allowed location

  2. 2.

    Ensure HTML keyword escape is used: escape must be used before inserting untrusted data on HTML element content.

  3. 3.

    Attribute should escape before inserting untrusted data into common HTML attribute.

  4. 4.

    Ensure JavaScript loophole is closed: use JavaScript escape before processing client request

  5. 5.

    Ensure CSS loophole is closed: Use CSS tag escape and strict validation tag in anonymous forms.

  6. 6.

    URL protection: Use URL escape before inserting untrusted data into URL parameters.

On the other hand, to prevent DOM base XSS, the followings guidelines are proposed:

  1. 1.

    Use HTTP only to secure base cookie.

  2. 2.

    Implement content security policy.

  3. 3.

    Use automated escaping JavaScript word template.

  4. 4.

    Use the X-XSS-Protection response header.

These guidelines are necessary for preventing XSS attack on a Web application. However, all these rules can be seen as basic recommendations for preventing web application on server side, there should also be XSS protection in web application codes. This can be done based on some special character remover from the search option. If we are going to use this type of mechanism in web application, then there should be significantly less chance to insert cross-site scripting attack into the web application. In the validation section, we must insert code that can prevent malicious code from web applications. It should not allow it to run on the client side as well. In the validation cycle, we must add validation because it will protect the web application from a cross-site scripting attack. In the validation, JavaScript or any other malicious script should be filtered at the client side. For instance, in the validation code, we can define a filter that remove the special character such as ,&,",> from the query. By filtering and removing these characters, a web application prevent a malicious user from injecting and executing malicious scripts on the web application [10].

Fig. 6.
figure 6

XSS Prevention flowchart

Full size image
Fig. 7.
figure 7

Validation flow

Full size image

In the validation section, encoding grabbing validation method can also be used. This is because a malicious user may try to break the validation used by a website. In such a case, an attacker could attempt to mask their attacks by encrypting the malicious payload and injecting into the web application. Consequently, if the website did not implement the “encrypted grabbing character validation”, then regular validation could be easily compromised. It is therefore necessary to use encrypted grabbing character validation (Fig. 6).

Figure 7 shows the flowchart needed for security proofing scripts in web application. The process is divided into the followings steps:

  • Step 1: Validation begins

  • Step 2: Check if there is any special character or any encrypted data in the request.

  • Step 3: If yes, then remove all special character and encrypted codes from the request

  • Step 4: Check plain wording string for blacklisted words or other items such as script, alert, prompt and cookie. If yes, then filter/remove these blacklisted words from the request

  • Step 5: make sure this process cannot be bypassed to access the server.

4 Conclusion

Cross-site scripting attacks present a significant challenge for securing web applications. These attacks do not only impact the security of a user’s browser but they extend to compromise the security of webservers as well. Given that there are various ways in which users can input data into a web application, it is possible for an attacker to exploit these cross-site scripting vulnerabilities at any time. Current solutions rely on client or server side validation methods to defend across cross-site scripting attacks. However, these solutions do not provide a cohesive prevention approach and remain vulnerable to attacks. Henceforth, this work proposed a framework, which encompasses a set of guidelines to improve websites’ resilience to cross-site scripting attacks. Future works will consider deigning a threat model, which includes various penetration tests. These tests will be used to assess and evaluate the strength of the proposed guidelines.