Keywords

1 Introduction

With rapid growth of resource-limited mobile devices, pervasive wireless infrastructure, geographical-based services on cloud computing platform simulate a new approach called Mobile Cloud Computing (MCC). In recent years, a huge number of applications targeted at mobile devices, including business, social networking, multimedia, health, games, news, etc., because, the mobile cloud provides Internet-based services to the users, regardless of geographical location. The architecture of mobile cloud computing is depicted in Fig. 1. Mobile terminals are connected to a mobile network through a base station that establishes the connections and functional interfaces between a mobile network and user terminals. Here, network operators can provide network services to the mobile subscribers based on the home agent (HA).

XSS is one of the leading security problem faced by the application developers of the mobile cloud. Since, the growing nature of the social networking sites exponentially, applications deployed by the mobile cloud are enabling the users to upload the information into the cloud [9].

Fig. 1.
figure 1

The architecture of mobile cloud computing environment

Full size image

Current approaches of defending against XSS attacks mainly concerns on effective detection and prevention of real-time XSS vulnerabilities from the cloud applications. These vulnerabilities if not removed could be exploited anytime.

1.1 Motivations and Contributions

Cross-site scripting attacks occur almost daily [10]. XSS made history with the Samy worm, which is the fastest spreading virus. The worm was a original type of virus that self-replicated by altering the profile pages of MySpace users and sending friend requests to its creator. The famous hacker Samy Kamkar, who ended up in hot water with authorities after the incident [1].

Recently, the popular social networking sites including Google, Facebook and Twitter have become the victim of these attacks [9]. Furthermore, cross-site scripting deficiencies found in the universal search engine of UK parliament website in 2014, Yahoo website in 2013, PayPal website in 2012, Hotmail website in 2011, Justin.tv website in 2009, Orkut website in 2008 and many more. Besides infections on social networking sites, XSS has been used for financial gain, most notably in attacks against e-commerce giant eBay. Cybercriminals injected malicious scripts into several listings for cheap iPhones. The scripts sent users to a spoofed login page that harvested their credentials. Therefore, there is a need for designing a novel solution to mitigate XSS attacks in web applications based on the mobile cloud environment. The contribution of the paper includes:

  1. 1.

    Presents a background on XSS attacks and their classification.

  2. 2.

    Demonstrates the exploitation mechanisms of a stored (persistent), reflected and DOM-based attacks.

  3. 3.

    Test the XSS vulnerabilities by inserting real world malevolent scripts on vulnerable web applications.

  4. 4.

    In order to find XSS vulnerabilities, we have focused on initiating a client-side cross-site scripting attack discovery and mitigation technique known as “Secure XSS layer” on browser javascript engine to filter malicious scripts.

  5. 5.

    We have estimated the accuracy and performance of the proposed framework using sensitivity and F-measure, which is very high and acceptable in contrast to the existing XSS filters.

1.2 Organization of the Article

The rest of the article is structured as follows: Sect. 2 describes the classes of XSS vulnerabilities. Section 3 covers related work, which includes XSS detection and prevention mechanisms. Section 4 describes the proposed secure XSS layer to mitigate XSS attacks in cloud based web applications. Section 5 demonstrates the performance evaluation. Section 6 concludes the paper.

2 Classifying XSS Vulnerabilities

Cross-site scripting attacks are classified into three types such as stored XSS, which is also known as persistent XSS attacks, reflected XSS also called non-persistent XSS attacks, DOM-based XSS attacks and one of the advanced XSS attack called binary encoding attack [12].

2.1 Stored XSS Attacks

The persistent XSS attacks arise if an attacker injects malevolent data into a web, where its cache permanently. In stored XSS, the malicious string originates from the website’s database. This XSS attack is persistent attack [9]. The best examples for stored XSS are forum posts and webmail messages. The stored XSS attack exploitation as shown in Fig. 2.

The following steps illustrate how stored XSS attack can be performed by an attacker to steal cookies.

  1. 1.

    Initially, an attacker \(\mathscr {A}\) makes use of website’s form to injection of malicious script into the cloud.

  2. 2.

    The cloud server receives script and stores in the application database.

  3. 3.

    The legitimate mobile user make a request for the content from application database of the mobile cloud.

  4. 4.

    The cloud server delivers the user request to the application database.

  5. 5.

    The Application database includes stored malicious script along with requested content in the response and sends it to the server.

  6. 6.

    Server receives the response message containing and delivers it to the mobile user.

  7. 7.

    The mobile user with browser executes the received malicious script.

  8. 8.

    This results, sending the victim’s cookie information to an attacker \(\mathscr {A}\).

Fig. 2.
figure 2

Stored XSS attack exploitation

Full size image

2.2 Reflected XSS Attacks

These non-persistent XSS attacks arise when the cloud server is unable to sanitize the output in an appropriate way [9].

The following steps describe how reflected XSS attack can be performed by an attacker to steal cookies.

  1. 1.

    An adversary \(\mathscr {A}\) crafts a URL containing a malevolent code, then transfers to the legal client’s browser.

  2. 2.

    The client browser is tricked by an adversary into requesting the URL of the cloud server.

  3. 3.

    The cloud server includes the malevolent code from the URL in the response.

  4. 4.

    The legal client browser executes this harmful script inside the response, sending the victim’s cookies to the attacker’s server.

Fig. 3.
figure 3

Cookie stealer code to send cookies to the hacker mail

Full size image

Consider the scenario, where user trying to access the universal website known as www.entrust.co in the cloud to accomplish confidential operation (online shopping). The cloud-based application on entrust.com makes use of cookies to cache confidential session information in victim browser. In addition, the victim may also browse a harmful site, say shashixss.com, and it would be tricked into clicking on the malicious link. If the crafted code is cookie stealing code, then it will steal a cookie from users who view that page. Using the cookie, an attacker can take control of victim account. To demonstrate this vulnerability we implemented a cookie stealer code shown in Fig. 3, which make use of \(cookie=HTTP~GET-VARS[cookie];\) to steal the cookie from the current URL and send it to the hacker mail using the PHP() mail function with a subject “Stolen cookies”.

2.3 DOM-Based XSS Attacks

Compromising a DOM (Document Object Model) will cause the client-side code to execute in an unexpected manner. The following steps explain how DOM-based XSS attack can be performed by an attacker to steal cookies.

  1. 1.

    An adversary crafts URL containing a malevolent code, transfers into the client browser.

  2. 2.

    The client browser is tricked by an adversary into requesting URL from the application of the mobile cloud.

  3. 3.

    The cloud server accepts the client request but does not incorporate malevolent content in the response message.

  4. 4.

    The user executes the malevolent content inside the response message by using the web browser, causing the malevolent code to be inserted into the page.

  5. 5.

    Finally, client browser execute malevolent code injected into the web page, transferring the user’s confidential information to an adversary’s server.

2.4 Binary Encoding Attacks

Binary encoding attack is one of the advanced XSS attack, in which an attacker uses HTML static links to encode the sensitive information like cookies [12]. In this attack, every malicious link import by an attacker is represented by single bit 0 or 1. Until now, the malicious links which are embedded statically in HTML web pages are assumed secure and safe. Regrettably, this method experiences security vulnerabilities. Consider an adversary, injects a huge number of crafted HTML static hyperlinks to the webpage of the trusted site, which is deployed in the mobile cloud. When the malicious string is executed in victim’s browser, the crafted HTML static links could be used to encode confidential information.

Fig. 4.
figure 4

Binary encoding attack for stealing cookie information.

Full size image

To illustrate binary encoding attacks, consider the scenario in which the script can execute a loop to transfer cookies data bit-by-bit under an adversary control to a cloud server. Figure 4 shows JavaScript source-code for binary encoding attack to steal cookies. Assume that the cookie contains 50 bits, an adversary injects 50 isolated pair of static image references to his personal domain, say shashixss.com. In next stage of this attack, an adversary goes through cookie values bit by bit and make use of the static references. These references are previously injected to encode the confidential data. Later, an adversary can reconstruct cookies by checking and analysing the log file of a cloud server at shashixss.000webhostapp.com.

3 Related Work

From several years, there has been plenty of research going on at industries and academic institutes to identify and defending against XSS attacks [4, 5, 11, 13, 15]. However, research is still on to discover effective solutions to mitigate XSS vulnerabilities in web applications.

In 2006, Kirda et al. [12] proposed a tool called Noxes, it is a client-side mechanism for defending against XSS attacks. This tool introduces personal firewalls for preventing the users against scripting attacks. Basically, it accepts the HTTP request connections and can either be allowed or blocked based on the firewall rules.

Later, Shahriar et al. [17] come up with an approach to identify XSS vulnerabilities using static analysis technique. However, their approach produces false positive and false negative results. In addition, Saxena et al. [16] proposed input validation vulnerabilities on the web applications, it commonly occurs due to usage of untrusted data, which is not validated. The work proposed by Saxena et al. [16] is unable to handle the complexity of sanitization errors.

In 2014, Alhamazani et al. [2] demonstrated several cloud security tools, their features, and shortcomings. In addition, they presented a taxonomy of current cloud monitoring tools with a focus on future research directions. In 2015, Gupta and Gupta [9] described cross-site scripting exploitation, discovery, and prevention. In addition, they also presented 11 major XSS attack incidents in previous years. Their analysis and state-of-art techniques led to conclude that cross-site scripting is a plague for cloud-based applications and it needs to be addressed.

Later, Fernandez et al. [6] proposed a security reference architecture for the cloud computing system. This architecture describes a conceptual model for a cloud-based system and provide a way to specify requirements for various applications deployed by a cloud.

Morsy et al. [3] presented a detailed analysis of the web security problem in the cloud. They investigated the problem from the cloud architecture perspective, the cloud service delivery models perspective and the cloud stakeholders perspective.

Recently, Gupta and Gupta [7] proposed a robust framework, it is deployed in the cloud environment to alleviate the propagation of JS worms. Unfortunately, the framework is unable to detect stored and DOM-based XSS vulnerabilities. In 2017, Gupta et al. [8] proposed an enhanced defensive framework for XSS. This framework scans all requests for the URI links that point the links of external files and which may contain malicious XSS payload. To defend against cross-site scripting attacks many XSS defensive techniques have been proposed. However, some of them have been proved to be insecure in the cloud environments.

4 The Proposed Approach to Mitigate XSS Attacks

The proposed approach involves a secure XSS interception layer placed in the client’s browser. The proposed layer is responsible to discover all malicious scripts that reaches the client browser, from all possible paths. Later, the secure XSS layer compares the received scripts with a list of valid scripts that are already by an administrator for the site being accessed, the received script is not in browser list being prevented from execution and protecting the system. The proposed layer make use of identifiers when comparing the browser scripts. The identifiers represents the elements present in the script and it’s execution context in the browser.

To defend cloud users against XSS attacks the proposed approach make use of training phase, where every benevolent script is promote by a identifier [14]. In training phase, only those statements backed by an identifier are approved for execution.

figure a

The identifier generation consists of a secure layer known as Secure XSS interception layer. The proposed layer wraps the mobile browser script engine, collects all components for identifier generation and verification process. Finally, the proposed method attempts to match the identifiers in the mobile browser list with the ones generated during execution of the browser content or during production mode.

The Secure XSS layer can detects variety of cross-site scripting attacks like stored (persistent), reflected (non-persistent), DOM-based attacks and some sophisticated attacks like mimic and binary encoding attacks. To mitigate the XSS attacks, we propose a secure XSS layer algorithm (Algorithm 1), which consists of the following steps:

  1. 1.

    An identifier generation is the first phase of secure XSS layer algorithm. In this phase, all benign scripts is mapped into identifiers, which is also known as script identifiers.

  2. 2.

    All script identifiers are stored in the backup table.

  3. 3.

    During script execution phase, the secure XSS layer verifies whether corresponding script identifier present in the backup table.

  4. 4.

    If the script is exist in the table, then it will be treated as benign script. In this phase, it also checks whether the script parameters are refers to an unexpected URLs.

  5. 5.

    If no similar script identifier is originate and any unregistered URL identifier is found, then the mobile user browser is under attack. In this scenario, the proposed layer can stop the further execution and forwards an alarm to the mobile user and cloud server administrator to notify the XSS attack.

5 Performance Evaluation

In this section, we demonstrate the implementation details, experimental results and performance analysis of the proposed secure web application approach.

5.1 Implementation

The proposed approach is implemented as a integrated module in the JavaScript engine of the browser. Further, we instrumented that API methods are entry points to the JavaScript engine which takes either input script as a string or executes the input statement that has already complied by the JavaScript engine.

The processing of script and document location is accomplished by the parser. The web browser make use of line number and codebase, then passes the script location within a document to API methods as the parameter. We can differentiate between external and internal scripts by examining the location of a script. To accumulate valid script identifiers, we designed an identifier generation module. In order to analyse effectiveness of the proposed algorithm, we have taken few vulnerable cloud based applications into account. The experiment involves installation of vulnerable cloud applications and attacking for real world cross-site scripting threats.

Table 1 describes five different classes of XSS attack vectors, including JavaScript attack vectors, encoded attack vectors, HTML malicious tags, malicious event-handler and URL attack vectors.

Table 1. XSS attack vectors and it’s example patterns.
Full size table

Initially, we applied the identifier generation module to the downloaded vulnerable application. Then, we changed to execution phase and performed several attacks based on vulnerability type of the applications. Deficiencies like improper verification of HTTP requests, absence of sanitization makes us to perform cookie stealing and redirect attacks. Especially, the phpMyFAQ vulnerable application is unable to sanitize URLs and making way to insert malicious JavaScript to steal cookies of the mobile browser.

In addition, we selected few vulnerable applications like eBay.com and nydailynews.com from XSSed.com archive. Initially, we applied the proposed secure layer in the context of mobile cloud to search for XSS attacks that make use of JavaScript. Further, we attempted various of attacks, including stored, DOM based and the threats that utilized the eval functions. The proposed layer successfully detected and blocked all of the vulnerabilities.

5.2 Performance Analysis Using F-Measure

F-Measure is defined as the harmonic mean of sensitivity and specificity. In this context, we compute specificity, sensitivity, and F-Measure for the proposed framework using observed experimental results on five vulnerable mobile cloud based applications. We have embedded various XSS attack vectors through injection points of the cloud based applications. We have chosen such applications for accessing HTML forms. Table 2 outlines the detail performance analysis of the proposed XSS defensive approach on different web applications. We analysed results of the proposed framework based on the number of malicious strings inserted, true negatives, true positives, and false negatives, false positives.

From Table 2, we can notice that the highest number of TPs (True Positives) are encountered in Humhub, Jcart, and phpMyFAQ. Furthermore, in all applications, the obtained rate of false negatives and false positives are acceptable. We can observe from Table 2 that the performance of proposed XSS defensive framework is almost 95% with respect to F-Measure of 0.95. The F-Measure generally analyses the performance of a system by calculating the harmonic mean of sensitivity and specificity. The authors in also proposed an approach to mitigate XSS attacks in cloud computing environment.

6 Conclusion

Mobile cloud environment involves a interconnection of several connecting devices to provide a different services to the users, which results a complex system and create many security issues. In the proposed approach, we designed the secure XSS framework, in order to deal with malicious scripts that reach a mobile user browser from all possible routes of the cloud server. In order to implement secure xss defensive framework, we wrapped all entry points of the JavaScript engine in mobile browser to execute the scripts based on the identifiers which are stored in the backup table. The script identifiers in the auxiliary table can be enriched with new elements and making the framework more robust. In this convenient way, the unwanted script elements can be removed from identifiers list to reduce computation overhead, but this practice makes the application framework more vulnerable to XSS threats. In order to assess the effectiveness of the proposed approach, a number of web applications implemented with scripting languages, such as PHP and ASP, have been submitted to the vulnerability analysis. This approach has been preliminarily tested using it to detect vulnerabilities in open source cloud based applications, the experimental results demonstrates that the proposed approach prevents the injection of untrusted attack vectors with low and acceptable false positive and false negatives.

Table 2. Performance analysis to compute F-Measure
Full size table