No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
mXSS attacks: Attacking well-secured web-applications by using innerHTML mutations
Abstract
Back in 2007, Hasegawa discovered a novel Cross-Site Scripting (XSS) vector based on the mistreatment of the backtick character in a single browser implementation. This initially looked like an implementation error that could easily be fixed. Instead, as this paper shows, it was the first example of a new class of XSS vectors, the class of mutation-based XSS (mXSS) vectors, which may occur in innerHTML and related properties. mXSS affects all three major browser families: IE, Firefox, and Chrome.
We were able to place stored mXSS vectors in high-profile applications like Yahoo! Mail, Rediff Mail, OpenExchange, Zimbra, Roundcube, and several commercial products. mXSS vectors bypassed widely deployed server-side XSS protection techniques (like HTML Purifier, kses, htmlLawed, Blueprint and Google Caja), client-side filters (XSS Auditor, IE XSS Filter), Web Application Firewall (WAF) systems, as well as Intrusion Detection and Intrusion Prevention Systems (IDS/IPS). We describe a scenario in which seemingly immune entities are being rendered prone to an attack based on the behavior of an involved party, in our case the browser. Moreover, it proves very difficult to mitigate these attacks: In browser implementations, mXSS is closely related to performance enhancements applied to the HTML code before rendering; in server side filters, strict filter rules would break many web applications since the mXSS vectors presented in this paper are harmless when sent to the browser.
This paper introduces and discusses a set of seven different subclasses of mXSS attacks, among which only one was previously known. The work evaluates the attack surface, showcases examples of vulnerable high-profile applications, and provides a set of practicable and low-overhead solutions to defend against these kinds of attacks.
... We demonstrate a similar example in Figure 3a, (1) A receives the following detailssender and receiver account numbers, amount, and bank code, (2) B validates the sender and receiver account numbers, bank code, and the amount before initiating sending process, and (3) D processes the money transfer from sender to receiver account. Here, B is performing mutation-attack by modifying the account number and the amount using the hard-coded values or inputs taken from other side-channels [8], Figure3b. Now D processes money transfer on the mutated data. ...
... The Arc follows annotation such as syntax similar to JML [13]. The current Arc implementation supports eight basic constructs: (1) @sameProcess; (2) @sameTask; (3) @read; (4) @write; (5) ∧; (6) ∨; (7) ¬; (8) impl − − →. The Arc grammar is given in Figure 5. Constraints describe the receiver's context, and the access keyword Page 7221 is used to specify the accessibility. ...
... Such attacks are classified as tricky ICC which µTent handles by using "@read" Arc contract limiting mutation of Intent data. The application set (7)(8)(9)(10)(11)(12) in Table 2 ...
Intents are the plain-text based message object used for ICC by the Android framework. Hence the framework essentially lacks an inbuilt security mechanism to protect the visibility, accessibility, and integrity of Intent's data that facilitates adversaries to intercept or manipulate the data. In this work, we investigate the Intent protection mechanism and propose a security-enhanced Intent library µTent that allows Android apps to securely exchange sensitive data during ICC. Differently from the existing mechanism, µTent provides accessibility and visibility of Intent data by validating the receiver's capability and provides integrity by using encryption and the Arc security contract code. Especially, ICC is initiated by exchanging µTent and follows a novel ownership-based key distribution model, that restricts the malware apps without permission from deciphering data. Through the evaluation, we show that µTent can improve the security for popular Android apps with minimal performance overheads, demonstrated using F-Droid apps.
... Conventionally, practitioners classify cross-site scripting into three main categories based on its exploitation technique namely reflected cross-site scripting, persistent cross-site scripting, and DOM-based cross-site scripting [20] [21]. Then, [22] and [23] successfully discovered another two cross-site scripting exploitation techniques called UTF-7 cross-site scripting and mutation cross-site scripting (mXSS). Figure 1 shows the taxonomy of crosssite scripting with both mutation cross-site scripting and UTF-7 cross-site scripting included. ...
... In the meanwhile, DOM-based cross-site scripting is a client-side scripting vulnerability, which this cross-site scripting attack directly modifies vulnerable web page's DOM document without sending the malicious script to the web server [21]. Then, [22] and [23] discover the mutation cross-site scripting and UTF7 cross-site scripting, which are the subclass of conventional reflected cross-site scripting, persistent cross-site scripting, and DOM-based cross-site scripting. Mutation cross-site scripting leverages browser default feature to convert the innocent string of text into malicious and executable client-side scripts. ...
... Similarly, mutation cross-site leverages default nature of modern web browser's to encode innocent text into the executable malicious script. Details regarding both mutation cross-site scripting and UTF7 cross-site scripting are reachable in [22] and [23]. ...
... Inputting the value Flora & Fauna into cat gives the desired HTML markup: When this is inserted into the DOM via innerHTML, an implicit browser transduction will take place, i.e., first HTML-unescaping the value inside the onclick attribute and invoking the attacker's script alert(1) after createCatList. This subtle XSS bug (a type of mutation XSS [33]) is due to calling the appropriate escaping functions in the wrong order. ...
... Example 1 is one example of analysis of mutation XSS vulnerabilities that can be expressed in our logic. In this paper, we provide three other mutation XSS examples that can be expressed in our logic (adapted from [33,38,62]). ...
... see [27,43,65]), which unrolls loops in the programs (up to a given depth) and converts the resulting programs into static single assign-ment form (i.e. each variable defined only once). For applications to detecting mutation XSS [33], we will see that the formula for analysing mutation XSS from Example 1 in Introduction can be expressed in the straight-line fragment. We will also see other such examples in this section. ...
We study the fundamental issue of decidability of satisfiability over string
logics with concatenations and finite-state transducers as atomic operations.
Although restricting to one type of operations yields decidability, little is
known about the decidability of their combined theory, which is especially
relevant when analysing security vulnerabilities of dynamic web pages in a more
realistic browser model. On the one hand, word equations (string logic with
concatenations) cannot precisely capture sanitisation functions (e.g.
htmlescape) and implicit browser transductions (e.g. innerHTML mutations). On
the other hand, transducers suffer from the reverse problem of being able to
model sanitisation functions and browser transductions, but not string
concatenations. Naively combining word equations and transducers easily leads
to an undecidable logic. Our main contribution is to show that the
"straight-line fragment" of the logic is decidable (complexity ranges from
PSPACE to EXPSPACE). The fragment can express the program logics of
straight-line string-manipulating programs with concatenations and
transductions as atomic operations, which arise when performing bounded model
checking or dynamic symbolic executions. We demonstrate that the logic can
naturally express constraints required for analysing mutation XSS in web
applications. Finally, the logic remains decidable in the presence of length,
letter-counting, regular, indexOf, and disequality constraints.
... For the purpose of this paper, two major XSS variants are relevant: reflected and stored XSS. We do not go into detail on DOM-based XSS [5] and mXSS [6], because home router admin interfaces do not have the necessary rich JavaScript code to execute these attacks; for example, the HTML DOM property innerHTML for executing mXSS attacks. e) Reflected XSS: The first step of a reflective XSS attack is to send attack vectors defined by the attacker to the server via an HTTP GET or POST request. ...
... The partial disclosure of Google's and Facebook's code injection bugs underlines that there is a massive attack surface. 6 One way to attack the victim is shown in Figure 1. There are three images with kittens and three boxes that list some properties of these images. ...
... 6 Bug Bounty: http://www.google.com/about/appsecurity/reward-program/, https://www.facebook.com/whitehat7 ...
In this paper we investigate the Web interfaces of several DSL home routers
that can be used to manage their settings via a Web browser. Our goal is to
change these settings by using primary XSS and UI redressing attacks. This
study evaluates routers from 10 different manufacturers (TP-Link, Netgear,
Huawei, D-Link, Linksys, LogiLink, Belkin, Buffalo, Fritz!Box, and Asus). We
were able to circumvent the security of all of them. To demonstrate how all
devices are able to be attacked, we show how to do fast fingerprinting attacks.
Furthermore, we provide countermeasures to make administration interfaces and
therefore the use of routers more secure.
... Heiderich et al. [66] study the prevalence of mutation XSS attacks (MXSS) and the suitability of existing techniques to defend against them. ...
... Transmitted messages are transformed (i.e., mutated) into valid scripts executed by the receiving browsers at rendering the content of messages. MXSS attacks are firstly reported in 2017 by Heiderich et al. [66]. ...
Cross-site scripting (XSS) is one of the major threats menacing the privacy of data and the navigation of trusted web applications. Since its reveal in late 1999 by Microsoft security engineers, several techniques have been developed in the aim to secure web navigation and protect web applications against XSS attacks. The problem became worse with the emergence of advanced web technologies such as Web services and APIs and new programming styles such as AJAX, CSS3 and HTML5. While new technologies enable complex interactions and data exchanges between clients and servers in the network, new programming styles introduce new and complicate injection flaws to web applications. XSS has been and still in the TOP 10 list of web vulnerabilities reported by the Open Web Applications Security Project (OWASP). Consequently, handling XSS attacks became one of the major concerns of several web security communities. In this paper, we contribute by conducting a systematic mapping and a comprehensive survey. We summarize and categorize existent endeavors that aim to protect against XSS attacks and develop XSS-free web applications. The present review covers 147 high quality published studies since 1999 including early publications of 2022. A comprehensive taxonomy is drawn out describing the different techniques used to prevent, detect, protect and defend against XSS attacks. Although the diversity of XSS attack types and the scripting languages that can be used to state them, the systematic mapping revealed a remarkable bias toward basic and JavaScript XSS attacks and a dearth of vulnerability repair mechanisms. The survey highlighted the limitations, discussed the potentials of existing XSS attack defense mechanisms and identified potential gaps.
... This is another class of XSS attacks discovered recently by PhD scholar Dr. Mario in 2018 which is the result of errors in inner HTML code and its properties which is used by the all modern browser to display the HTML content to the user before being filtered by the server. Dr. Mario in [2] introduced six new sub-classes of mXSS attacks which were not known before their study. Since mXSS is recursive in nature and the iteration is highly unpredictable, it is named as mutated XSS or mutation based XSS. ...
... Sample DOM-XSS attack scenario[2] II. DEFENESE MECHANISMS AGAINST XSS ATTACKS Several defense mechanisms have been proposed till date for defending against XSS attacks. ...
XSS attacks have become more prevalent in last few decades and thus more challenging to detect their existence. XSS attacks are broadly classified into two categories: server-based XSS attack and client-based XSS attack. Although a lot of research has already been done in this area, still the methods lack in precision and accuracy as per the literature survey. There are ample of methodologies being applied in the detection of XSS attacks using supervised learning, unsupervised learning, reinforcement learning, deep learning and metaheuristic algorithms. We present a survey of the recent approaches being applied by the numerous researchers in their proposed models. Following indexed journals were used for research papers’ collection in order to carry out a survey: Elsevier, Springer, IEEE explore, Hindawi, google scholar, and Web of Science. Moreover, in this paper, we introduce a classification chart of several machine learning algorithms that can be applied to the web-attack detection model.
(PDF) A Detailed Survey on Recent XSS Web-Attacks Machine Learning Detection Techniques. Available from: https://www.researchgate.net/publication/356078785_A_Detailed_Survey_on_Recent_XSS_Web-Attacks_Machine_Learning_Detection_Techniques [accessed Nov 15 2021].
... Lots of research has been conducted for testing of web applications. Such works focus either on strengthening the detection mechanisms against attacks [28,30] or take the role of the attacker [19,27,31]. The latter case is covered, among others, by approaches from the area of model-based testing [24]. ...
... The authors of [27] introduce a mutation-based XSS testing approach that exploits intrinsic security leaks in web browsers. In this approach, malicious attack vectors are stored in their "harmless form" in HTML markups. ...
Chatbots, i.e., systems that communicate in natural language, have been of increasing importance over the last few years. These virtual agents provide specific services or products to clients on a 24/7 basis. Chatbots provide a simple and intuitive interface, i.e., natural language processing, which makes them increasingly attractive for various applications. In fact, chatbots are used as substitutes for repetitive tasks or user inquiries that can be automated. However, these advantages always are accompanied with concerns, e.g., whether security and privacy can be assured. These concerns become more and more important, because in contrast to simple requests, more sophisticated chatbots are able to utilize personalized services to users. In such cases, sensitive user data are processed and exchanged. Hence, such systems become natural targets for cyber-attacks with unforeseen consequences. For this reason, assuring information security of chatbots is an important challenge in practice. In this paper, we contribute to this challenge and introduce an automated security testing approach for chatbots. The presented framework is able to generate and run tests in order to detect intrinsic software weaknesses leading to the XSS vulnerability. We assume a vulnerability to be triggered when obtaining critical information from or crashing the virtual agent, regardless of its purpose. We discuss the underlying basic foundations and demonstrate the testing approach using several realworld chatbots.
... Techniques like (Agten et al. 2012;Rocha and Souto 2014;Dong et al. 2014;Wang et al. 2014) perform the Taint Tracking (Ttrac) of the untrusted variables of JavaScript attack vectors and accordingly performs the sanitization on them. Nevertheless, the existing work (Nunan et al. 2012;Shar and Tan (2012a, b); Huang et al. 2004;Heiderich et al. 2013) tracks the flow of tainted data in a static manner that is completely ineffective form of taint tracking. Code Rewriting (CRW) is the technique of proper isolation of untrusted JavaScript content from the actual data of web page. ...
... Code Rewriting (CRW) is the technique of proper isolation of untrusted JavaScript content from the actual data of web page. Recent client-side frameworks (Huang et al. 2004;Heiderich et al. 2013) adopt this technique and accordingly proceed with their respective defensive mechanisms. But techniques like (Pelizzi and Sekar 2012;Bates et al. 2010;Giorgio 2018;David 2008;Jeremias 2008) didn't perform such isolation and increased the overall complexity and runtime overhead of their work. ...
XSS is well-thought-out to be an industry-wide problem that is affecting the diverse contemporary web platforms. The collection of most recent web application reports revealed that XSS reserved the topmost position among all other cyber-attacks. This survey article wishes to present the improvements related to XSS worm defensive methodologies. We have enlarged our discussion to different classes of XSS attacks, i.e., non-persistent, persistent, DOM-Based and mutation-based XSS attacks that has recently stated in the state-of-art. This complete survey offers full vision into the classification, avoidance, recognition and alleviation mechanisms of such attacks. In addition, broad solution classification has been designed for the classification of approaches used by numerous contributions. This article discusses the impact of real world XSS worms and the associated recent real world incidents of such worms. Existing client-side, server-side, proxy-enabled and certain other XSS defensive techniques was presented with an aim to recognize their key contributions and the current performance concerns. In the end, we present certain future research guidelines, a complete mechanism and the associated requirements towards the designing of an effective and robust XSS defensive methodology.
... To explain the need for a hybrid model, the various attacks that can be used to create a data security breach must be considered. Common attacks that are utilized to carry out data breaches are SQL Injection (SQLI) [12], brute-force [13], buffer overflows [14], Cross-Site Scripting (XSS) [15], Remote File Inclusion (RFI) [70], Directory Traversal (DT) [71] and Cross-Site Request Forgery (CSRF) [16] to name a few. In addition, hybrid models have a central focus on the newest threat: polymorphic attacks [17]. ...
... Chou [12] used web servers that were hosted in a Cloud environment to detect SQL injections, XSS, and brute-force attacks. Finally, in [15] the researchers looked at innerHTML properties such as GET, HTTP header and cookies to determine the presence of mutation-based XSS attacks, denoted as mXSS. This work, in contrast, uses logs collected from both the web server and the MySQL database for analysis. ...
Web application security is a definite threat to the world’s information technology infrastructure. The Open Web Application Security Project (OWASP), generally defines web application security violations as unauthorized or unintentional exposure, disclosure, or loss of personal information. These breaches occur without the company’s knowledge and it often takes a while before the web application attack is revealed to the public, specifically because the security violations are fixed. Due to the need to protect their reputation, organizations have begun researching solutions to these problems. The most widely accepted solution is the use of an Intrusion Detection System (IDS). Such systems currently rely on either signatures of the attack used for the data breach or changes in the behavior patterns of the system to identify an intruder. These systems, either signature-based or anomaly-based, are readily understood by attackers. Issues arise when attacks are not noticed by an existing IDS because the attack does not fit the pre-defined attack signatures the IDS is implemented to discover. Despite current IDSs capabilities, little research has identified a method to detect all potential attacks on a system. This thesis intends to address this problem. A particular emphasis will be placed on detecting advanced attacks, such as those that take place at the application layer. These types of attacks are able to bypass existing IDSs, increase the potential for a web application security breach to occur and not be detected. In particular, the attacks under study are all web application layer attacks. Those included in this thesis are SQL injection, cross-site scripting, directory traversal and remote file inclusion. This work identifies common and existing data breach detection methods as well as the necessary improvements for IDS models. Ultimately, the proposed approach combines an anomaly detection technique measured by cross entropy and a signature-based attack detection framework utilizing genetic algorithm. The proposed hybrid model for data breach detection benefits organizations by increasing security measures and allowing attacks to be identified in less time and more efficiently.
... In 2013, Dr. Mario found a new type of XSS attack called mutation XSS (Heiderich et al., 2013). Due to the obvious variances in browser interpretation of HTML standards, M-XSS is self-referential, and the iteration is very uncertain. ...
With the rising demand for E-commerce, Social Networking websites, it has become essential to develop security protocols over the World Wide Web that can provide security and privacy to Internet users all over the globe. Several traditional encryption techniques and attack detection protocols can secure the data transmitted over public networks. However, hackers can effortlessly exploit them to acquire access to the users’ sensitive information such as user ID, session ID, cookies, passwords, bank account details, contact numbers, private PINs, database information, etc. Researchers have continuously innovated new techniques to build a secure and robust system that cannot be easily hacked and manipulated. Still, there is much scope for novelty to provide security against contemporary techniques used by intruders. The motivation of this survey is to observe the recent developments in Cross-Site Scripting attacks and techniques used by researchers to secure confidential information. Cross-Site Scripting (XSS) has been recognized as one of the top 10 online application security risks by the Open Web Application Security Project (OWASP) for decades. Therefore, dealing with this security flaw in web applications has become essential to avoid further personal and financial damage to Internet users and business organizations. There is a need for an extensive survey of recent XSS attack detection techniques that can provide the right direction to researchers and security professionals. We present a complete overview of recent machine learning and neural network-based XSS attack detection techniques in this paper, covering deep neural networks, decision trees, web-log-based detection models, and many more. This paper also highlights the research gaps that must be addressed while designing attack detection models. Further, challenges researchers face during the development of recent techniques are also discussed. Finally, future directions are provided to reflect on new concepts that can be used in forthcoming research works to improve XSS attack detection techniques.
... Some attack vectors are produced by the evolved strategies used by attackers, such as the mutation of some HTML events and properties, including innerHTML, outerHTML, etc. These new classes of XSS can be considered a sudden drift caused by bypassing almost all the XSS filters on the server-side and client-side (Heiderich et al., 2013). ...
Web applications’ popularity has raised attention in various service domains, which increased the concern about cyber-attacks. One of these most serious and frequent web application attacks is a Cross-site scripting attack (XSS). It causes grievous harm to victims. Existing security methods against XSS fail due to the evolving nature of XSS attacks. One evolving aspect of XSS attacks is feature drift which changes the feature relevancy and causes degradation in the performance. Unfortunately, dynamic awareness of drift occurrence is missing. Thus, this study attempts to fill the gap by proposing a feature drift-aware algorithm for detecting the evolved XSS attacks. The proposed approach is a dynamic feature selection based on a deep Q-network multi-agent feature selection (DQN-MAFS) framework. Each agent is associated with one feature and is responsible for selecting or deselecting its feature. DQN-MAFS provides a sub-model for reward distribution over agents, which is named as fair agent reward distribution based dynamic feature selection FARD-DFS. This framework is capable of supporting real-time, dynamic updates and adjustment of embedded knowledge as long as new labelled data arrives. DQN-MAFS has been evaluated using four real XSS attack datasets with various feature length sizes. The evaluation process was conducted and compared with state-of-the-art works. The obtained results show the superiority of our FARD-DFS over the benchmarks in terms of the majority of metrics. The improvement percentages of the mean accuracy and F1-measure ranged from 1.01% to 12.1% and from 0.55% to 6.88%, respectively, in comparison with the benchmarks. This approach can be deployed as an autonomous detection system without the need for any offline retraining process of the model to detect the evolved XSS attack.
... This notion of three types of XSS has been upheld for years in research [32,36,43] and widely accepted textbooks [67]. Apart from these, all other types of XSS have been treated as niche problems (e.g., mutation-based XSS [19]). Similarly, due to the absence of empirical evidence about its prevalence, Cross-Site Scripting enabled by persistence APIs on the client has not been acknowledged as an important type of XSS. ...
... This is done via The Closure Library [co 2015] string functions htmlEscape and escapeString. Inputting the value Tom & Jerry into name gives the desired HTML markup: On the other hand, inputting value ');attackScript();// to name, results in the markup: Before this string is inserted into the DOM via innerHTML, an implicit browser transduction will take place [Heiderich et al. 2013;Weinberger et al. 2011], i.e., HTML-unescaping the string inside the onclick attribute and then invoking the attacker's script attackScript() after viewPerson. This subtle DOM-based XSS bug is due to calling the right escape functions, but in wrong order. ...
String analysis is the problem of reasoning about how strings are manipulated by a program. It has numerous applications including automatic detection of cross-site scripting, and automatic test-case generation. A popular string analysis technique includes symbolic executions, which at their core use constraint solvers over the string domain, a.k.a. string solvers. Such solvers typically reason about constraints expressed in theories over strings with the concatenation operator as an atomic constraint. In recent years, researchers started to recognise the importance of incorporating the replace-all operator (i.e. replace all occurrences of a string by another string) and, more generally, finite-state transductions in the theories of strings with concatenation. Such string operations are typically crucial for reasoning about XSS vulnerabilities in web applications, especially for modelling sanitisation functions and implicit browser transductions (e.g. innerHTML). Although this results in an undecidable theory in general, it was recently shown that the straight-line fragment of the theory is decidable, and is sufficiently expressive in practice. In this paper, we provide the first string solver that can reason about constraints involving both concatenation and finite-state transductions. Moreover, it has a completeness and termination guarantee for several important fragments (e.g. straight-line fragment). The main challenge addressed in the paper is the prohibitive worst-case complexity of the theory (double-exponential time), which is exponentially harder than the case without finite-state transductions. To this end, we propose a method that exploits succinct alternating finite-state automata as concise symbolic representations of string constraints. In contrast to previous approaches using nondeterministic automata, alternation offers not only exponential savings in space when representing Boolean combinations of transducers, but also a possibility of succinct representation of otherwise costly combinations of transducers and concatenation. Reasoning about the emptiness of the AFA language requires a state-space exploration in an exponential-sized graph, for which we use model checking algorithms (e.g. IC3). We have implemented our algorithm and demonstrated its efficacy on benchmarks that are derived from cross-site scripting analysis and other examples in the literature.
... Since the first formal reference to XSS in a CERT advisory in 2000 [6], generations of researchers and practitioners have investigated ways to detect [18,21,29,35], prevent [22,25,34] and mitigate [4,23,28,33] the issue. Despite these efforts, XSS is still one of the most prevalent security issues on the web [24,30,37], and new variations are constantly being discovered as the web evolves [5,13,14,20]. ...
Content Security Policy is a web platform mechanism designed to mitigate cross-site scripting (XSS), the top security vulnerability in modern web applications. In this paper, we take a closer look at the practical benefits of adopting CSP and identify significant flaws in real-world deployments that result in bypasses in 94.72% of all distinct policies. We base our Internet-wide analysis on a search engine corpus of approximately 100 billion pages from over 1 billion hostnames; the result covers CSP deployments on 1,680,867 hosts with 26,011 unique CSP policies -- the most comprehensive study to date. We introduce the security-relevant aspects of the CSP specification and provide an in-depth analysis of its threat model, focusing on XSS protections. We identify three common classes of CSP bypasses and explain how they subvert the security of a policy. We then turn to a quantitative analysis of policies deployed on the Internet in order to understand their security benefits. We observe that 14 out of the 15 domains most commonly whitelisted for loading scripts contain unsafe endpoints; as a consequence, 75.81% of distinct policies use script whitelists that allow attackers to bypass CSP. In total, we find that 94.68% of policies that attempt to limit script execution are ineffective, and that 99.34% of hosts with CSP use policies that offer no benefit against XSS. Finally, we propose the "strict-dynamic" keyword, an addition to the specification that facilitates the creation of policies based on cryptographic nonces, without relying on domain whitelists. We discuss our experience deploying such a nonce-based policy in a complex application and provide guidance to web authors for improving their policies.
... In 2007, Hasegawa introduced a novel XSS vector known as mutation XSS (mXSS)[Heiderich, (2013)]. The main reason behind this attack is that the server side and client side filters assumes that they both have identical understanding of content generated by the HTML code. ...
Nowadays, users of Online Social Network (OSN) are less familiar with cyber security threats that occur in such networks, comprising Cross-Site Scripting (XSS) worms, Distributed Denial of Service (DDoS) attacks, Phishing, etc. Numerous defensive methodologies exist for mitigating the effect of DDoS attacks and Phishing vulnerabilities from OSN. However, till now, no such robust defensive solution is proposed for the complete alleviation of XSS worms from such networks. This chapter discusses the detailed incidences of XSS attacks in the recent period on the platforms of OSN. A high level of taxonomy of XSS worms is illustrated in this article for the precise interpretation of its exploitation in multiple applications of OSN like Facebook, Twitter, LinkedIn, etc. We have also discussed the key contributions of current defensive solutions of XSS attacks on the existing platforms of OSN. Based on this study, we identified the current performance issues in these existing solutions and recommend future research guidelines.
... In [17], the NoScript plugin for Firefox browser was bypassed through an Error Based SQL injection flaw, while in [18] it was proved that the XSS filter of Internet Explorer can be easily bypassed by taking advantage of techniques that turn injected untrusted data into trusted data, which is not subject to validation by Internet Explorer's XSS filter. Recently, a new class of XSS attacks was discovered named as mutation-based XSS (mXSS) [19] that may occur in innerHTML and related DOM Javascript properties. The mutation-based XSS (mXSS) attack vectors affect all three major browsers (i.e., Chrome, Firefox and MS Inter Explorer). ...
XSS attacks have become very common nowadays, due to bad-written PHP web applications. In order to provide users with rudimentary protection against XSS attacks most web browser vendors have developed built-in protection mechanisms, called XSS filters. In this paper, we analyze two attacks that take advantage of poorly written PHP code to bypass the XSS filter of WebKit engine named XSS Auditor and perform XSS attacks. In particular, the first attack is called PHP Array Injection, while the second attack is a variant of the first one and it is named as PHP Array-like Injection. Both attacks take advantage of improper management of variables and arrays in PHP code to bypass the XSS Auditor. We elaborate on these attacks by presenting concrete examples of poorly written PHP code and constructing attack vectors to bypass the XSS Auditor. To defend against the identified attacks, we provide proper code writing rules for developers, in order to build secure web applications. Additionally, we have managed to patch the XSS Auditor, so that it can detect our identified XSS attacks.
... Several approaches have been proposed to address this challenge, including Bek [12], CSAS [13], ScriptGard [14], etc. Unfortunately, new attacks are constantly proposed to defeat the filtering logic in the existing sanitization mechanisms [15], [16]. We can adopt some of the sanitization methods to remove script from string to prevent the attack; however, the challenge is to decide where to place the sanitization logic. ...
HTML5-based mobile apps become more and more popular, mostly because they are
much easier to be ported across different mobile platforms than native apps.
HTML5-based apps are implemented using the standard web technologies, including
HTML5, JavaScript and CSS; they depend on some middlewares, such as PhoneGap,
to interact with the underlying OS.
Knowing that JavaScript is subject to code injection attacks, we have
conducted a systematic study on HTML5-based mobile apps, trying to evaluate
whether it is safe to rely on the web technologies for mobile app development.
Our discoveries are quite surprising. We found out that if HTML5-based mobile
apps become popular--it seems to go that direction based on the current
projection--many of the things that we normally do today may become dangerous,
including reading from 2D barcodes, scanning Wi-Fi access points, playing MP4
videos, pairing with Bluetooth devices, etc. This paper describes how
HTML5-based apps can become vulnerable, how attackers can exploit their
vulnerabilities through a variety of channels, and what damage can be achieved
by the attackers. In addition to demonstrating the attacks through example
apps, we have studied 186 PhoneGap plugins, used by apps to achieve a variety
of functionalities, and we found that 11 are vulnerable. We also found two real
HTML5-based apps that are vulnerable to the attacks.
... We applied the process iteratively, running new scans and collecting new payloads. We also added specific test cases for DOM XSS vulnerabilities, one of the most recently discovered and emerging sub-classes of XSS flaws [8,11], not included in previous works. It is worth noting that our research is not limited to individual scanners: we observed how cross-scanner analysis yields very interesting results. ...
Since the first publication of the "OWASP Top 10" (2004), cross-site
scripting (XSS) vulnerabilities have always been among the top 5 web
application security bugs. Black-box vulnerability scanners are widely used in
the industry to reproduce (XSS) attacks automatically. In spite of the
technical sophistication and advancement, previous work showed that black-box
scanners miss a non-negligible portion of vulnerabilities, and report
non-existing, non-exploitable or uninteresting vulnerabilities. Unfortunately,
these results hold true even for XSS vulnerabilities, which are relatively
simple to trigger if compared, for instance, to logic flaws.
Black-box scanners have not been studied in depth on this vertical: knowing
precisely how scanners try to detect XSS can provide useful insights to
understand their limitations, to design better detection methods. In this
paper, we present and discuss the results of a detailed and systematic study on
6 black-box web scanners (both proprietary and open source) that we conducted
in coordination with the respective vendors. To this end, we developed an
automated tool to (1) extract the payloads used by each scanner, (2) distill
the "templates" that have originated each payload, (3) evaluate them according
to quality indicators, and (4) perform a cross-scanner analysis. Unlike
previous work, our testbed application, which contains a large set of XSS
vulnerabilities, including DOM XSS, was gradually retrofitted to accomodate for
the payloads that triggered no vulnerabilities.
Our analysis reveals a highly fragmented scenario. Scanners exhibit a wide
variety of distinct payloads, a non-uniform approach to fuzzing and mutating
the payloads, and a very diverse detection effectiveness.
... Stock et al.'s recent work fuzzes and detects Type-0 XSS in a white-box harness [44]. Heiderich et al. detect in black-box mutation-based XSS caused by browser parser quirks [19]. LigRE+KameleonFuzz is a black-box fuzzer which targets Type-1 and 2 XSS. ...
We present a black-box based smart fuzzing approach to detect cross-site scripting (XSS) vulnerabilities in web applications. The smartness is attributed to model inference and automated malicious input generation. The former is implemented as a state-aware crawler which models the application as an automaton. The second component, evolutionary fuzzing, uses genetic algorithm (GA). To limit its search space, we introduce an Attack Grammar that mimics attackers by generating malicious inputs.
XSS are characterized by a relationship between tainted input and output of the web application. In black-box testing, precisely capturing this relationship is a non-trivial task that we solve using taint inference techniques. By doing so, we focus only on the transitions wherein this relationship holds and thereby avoid to fuzz the whole system. GA automates the process of generating inputs by considering the states of the application and evolving the inputs to trigger XSS, if any. Empirical evaluation shows that our fuzzer detects vulnerabilities missed by other blackbox scanners.
Cross-site scripting (XSS) is one of the major threats menacing the privacy of data and the navigation of trusted web applications. Since its disclosure in late 1999 by Microsoft security engineers, several techniques have been developed with the aim of securing web navigation and protecting web applications against XSS attacks. XSS has been and is still in the top 10 list of web vulnerabilities reported by the Open Web Applications Security Project (OWASP). Consequently, handling XSS attacks has become one of the major concerns of several web security communities. Despite the numerous studies that have been conducted to combat XSS attacks, the attacks continue to rise. This motivates the study of how the interest in XSS attacks has evolved over the years, what has already been achieved to prevent these attacks, and what is missing to restrain their prevalence. In this paper, we conduct a systematic mapping and a comprehensive survey with the aim of answering all these questions. We summarize and categorize existing endeavors that aim to handle XSS attacks and develop XSS-free web applications. The systematic mapping yielded 157 high-quality published studies. By thoroughly analyzing those studies, a comprehensive taxonomy is drawn out outlining various techniques used to prevent, detect, protect, and defend against XSS attacks and vulnerabilities. The study of the literature revealed a remarkable interest bias toward basic (84.71%) and JavaScript (81.63%) XSS attacks as well as a dearth of vulnerability repair mechanisms and tools (only 1.48%). Notably, existing vulnerability detection techniques focus solely on single-page detection, overlooking flaws that may span across multiple pages. Furthermore, the study brought to the forefront the limitations and challenges of existing attack detection and defense techniques concerning machine learning and content-security policies. Consequently, we strongly advocate the development of more suitable detection and defense techniques, along with an increased focus on addressing XSS vulnerabilities through effective detection (hybrid solutions) and repair strategies. Additionally, there is a pressing need for more high-quality studies to overcome the limitations of promising approaches such as machine learning and content-security policies while also addressing diverse XSS attacks in different languages. Hopefully, this study can serve as guidance for both the academic and practitioner communities in the development of XSS-free web applications.
Content Security Policy (CSP) is a World Wide Web Consortium (W3C) standard, designed to prevent and mitigate security vulnerabilities such as Cross-Site Scripting attacks (XSS), data injection attacks and clickjacking attacks on websites. In this paper, we present a newly discovered front-end web attack that uses the current object storage services vulnerability of cloud vendors to bypass CSP. We selected the object storage services from two cloud vendors with the most users, i.e, Google and Amazon, to conduct systematic and large-scale research and analysis. Three cyberspace search engines are used to retrieve data, from which we analyze the consequence and damage range of this security breach. We focus on reporting four key-aspects of this security breach: 1.how to use object storage services to bypass CSP; 2.analysis on the existences of such vulnerability in real-world websites; 3.analysis on the existing security vulnerabilities in current object storage services; 4.the new strategy on object storage services that we propose to use to eliminate the discovered security threat.
Single Sign-On protocols (SSO) are used to grant a web user authenticated access to many web applications after a single manual login. On the client side, SSO protocols like OAuth, OpenID Connect, or SAML rely on standard web browser features. The blueprint for modern SSO protocols is the Kerberos protocol [56] described in chapter 14.
The e-government puts forward the growing security demands on information system, in this context, thin client based solution appears. The thin client provides similar functions but better security by cloud storage and centralized management as rich client. The main technologies are virtual desktop infrastructure (VDI) and Web client by now. Recently the development of Web-based operating system (Web OS) promotes Web client. But these Web OSes mainly aim at mobility and cross-platform, give less confidentiality and integrity support for e-government. Firstly, this paper analyzes four open source Web OSes on their application type, access control policies and their security problems. Then it abstracts the common security model of Web OSes. Secondly, based on this common security model, it constructs a LBACWeb (Lattice-based access control model for Web OS) model, which combining confidential label, integrity label and category set on the basis of lattice structure. Finally, it proposes the least privilege principle on trusted subjects and define a special privileged subject to enhance the flexibility and usability. The analysis and verification are given at last to elaborate the security and applicability of the LBACWeb model.
Nowadays, users of Online Social Network (OSN) are less familiar with cyber security threats that occur in such networks, comprising Cross-Site Scripting (XSS) worms, Distributed Denial of Service (DDoS) attacks, Phishing, etc. Numerous defensive methodologies exist for mitigating the effect of DDoS attacks and Phishing vulnerabilities from OSN. However, till now, no such robust defensive solution is proposed for the complete alleviation of XSS worms from such networks. This chapter discusses the detailed incidences of XSS attacks in the recent period on the platforms of OSN. A high level of taxonomy of XSS worms is illustrated in this article for the precise interpretation of its exploitation in multiple applications of OSN like Facebook, Twitter, LinkedIn, etc. We have also discussed the key contributions of current defensive solutions of XSS attacks on the existing platforms of OSN. Based on this study, we identified the current performance issues in these existing solutions and recommend future research guidelines.
Injection attacks top the lists of the most harmful software vulnerabilities. Injection vulnerabilities are both commonplace and easy to exploit, which makes development of injection protection schemes important. In this article, we show how injection attacks can be practically eliminated through the use of structured data paired with cryptographic verification codes upon transmission.
Cross-Site Scripting (XSS) is an unremitting problem for the Web. Since its initial public documentation in 2000 until now, XSS has been continuously on top of the vulnerability statistics. Even though there has been a considerable amount of research and developer education to address XSS on the source code level, the overall number of discovered XSS problems remains high. Because of this, various approaches to mitigate XSS have been proposed as a second line of defense, with HTML sanitizers, Web Application Firewalls, browser-based XSS filters, and the Content Security Policy being some prominent examples. Most of these mechanisms focus on script tags and event handlers, either by removing them from user-provided content or by preventing their script code from executing.
In this paper, we demonstrate that this approach is no longer sufficient for modern applications: We describe a novel Web attack that can circumvent all of theses currently existing XSS mitigation techniques. In this attack, the attacker abuses so called script gadgets (legitimate JavaScript fragments within an application's legitimate code base) to execute JavaScript. In most cases, these gadgets utilize DOM selectors to interact with elements in the Web document. Through an initial injection point, the attacker can inject benign-looking HTML elements which are ignored by these mitigation techniques but match the selector of the gadget. This way, the attacker can hijack the input of a gadget and cause processing of his input, which in turn leads to code execution of attacker-controlled values. We demonstrate that these gadgets are omnipresent in almost all modern JavaScript frameworks and present an empirical study showing the prevalence of script gadgets in productive code. As a result, we assume most mitigation techniques in web applications written today can be bypassed.
To prevent Cross-Site Scripting (XSS) and related attacks, sanitation of untrusted content is usually performed either on the server side, or by client-side filters like XSS Auditor or NoScript. However, modern web applications (including mobile apps) may not be able to rely on these mechanisms any more since untrusted content may pass these filters as ciphertext or may completely be processed within the DOM of the browser/app. To cope with this problem, XSS sanitation within the Document Object Model (DOM) is required. This poses a novel technical challenge: A DOM-based sanitizer must rely on native JavaScript functions. However, in the DOM, any function or property can be overwritten, through a class of attacks called DOM Clobbering. We present a two-part solution: First we show how to embed any server or client side filtering technology securely into the DOM. Second, we give an example instantiation of an XSS filter which is highly efficient when implemented in Javascript. Both parts are combined into a working and battle-tested proof-of-concept implementation called DOMPurify.
Markup Injection (MI) attacks, ranging from classical Cross-Site Scripting (XSS) and DOMXSS to Scriptless Attacks, pose a major threat for web applications, browser extensions, and mobile apps. To mitigate MI attacks, we propose JSAgents, a novel and flexible approach to defeat MI attacks using DOM meta-programming. Specifically, we enforce a security policy on the DOM of the browser at a place in the markup processing chain “just before” the rendering of the markup. This approach has many advantages: Obfuscation has already been removed from the markup when it enters the DOM, mXSS attack vectors are visible, and, last but not least, the (client-side) protection can be individually tailored to fit the needs of web applications.
In this paper, the authors analyzed and discussed the performance issues in the existing cross-site scripting (XSS) filters and based on that, proposed a JavaScript string comparison and context-aware sanitization-based framework, XSS-immune. It is a browser-resident framework that compares the set of scripts embedded in hypertext transfer protocol request (HREQ) and hypertext transfer protocol response (HRES) for discovering any similar untrusted/malicious JavaScript code. This similar code points towards the untrusted JavaScript code that will be utilized by an attacker to exploit the vulnerabilities of XSS worms. In addition, our technique determines the context of such worms and performs the sanitization on them accordingly for alleviating the effect of such XSS worms from the real world web applications. We have also introduced a mechanism that can detect the injection of malicious parameter values by modifying the existing JavaScript code, that is, partial script injections. The prototype of XSS-immune was developed in Java and installed as an extension on the Google Chrome. In addition, we have verified the implementation of our design of prototype against five open-source XSS attack vector repositories, and very few XSS attack worms were able to evade our proposed design. Experimental evaluation and testing of XSS-immune were performed by adding support from the tested suite of real world web applications. The performance evaluation results revealed that our framework is able to detect the XSS worms with acceptable low false positive and false negative rate in comparison with the performance of existing XSS filters. Experimental results also incurred acceptable runtime overhead because of minor alterations on client-side browser and computationally fast execution of modules deployed in our browser-resident framework. Copyright
Web application attacks are an extreme threat to the world's information technology infrastructure. A web application is generally defined as a client-server software application where the client uses a user interface within a web browser. Most users are familiar with web application attacks. For instance, a user may have received a link in an email that led the user to a malicious website. The most widely accepted solution to this threat is to deploy an Intrusion Detection System (IDS). Such a system currently relies on signatures of the predefined set of events matching with attacks. Issues still arise as all possible attack signatures may not be defined before deploying an IDS. Attack events may not fit with the pre-defined signatures. Thus, there is a need to detect new types of attacks with a mutated signature based detection approach. Most traditional literature works describe signature based IDSs for application layer attacks, but several works mention that not all attacks can be detected. It is well known that many security threats can be related to software or application development and design or implementation flaws. Given that fact, this work expands a new method for signature based web application layer attack detection. We apply a genetic algorithm to analyze web server and database logs and the log entries. The work contributes to the development of a mutated signature detection framework. The initial results show that the suggested approach can detect specific application layer attacks such as Cross-Site Scripting, SQL Injection and Remote File Inclusion attacks.
We study the fundamental issue of decidability of satisfiability over string logics with concatenations and finite-state transducers as atomic operations. Although restricting to one type of operations yields decidability, little is known about the decidability of their combined theory, which is especially relevant when analysing security vulnerabilities of dynamic web pages in a more realistic browser model. On the one hand, word equations (string logic with concatenations) cannot precisely capture sanitisation functions (e.g. htmlescape) and implicit browser transductions (e.g. innerHTML mutations). On the other hand, transducers suffer from the reverse problem of being able to model sanitisation functions and browser transductions, but not string concatenations. Naively combining word equations and transducers easily leads to an undecidable logic. Our main contribution is to show that the "straightline fragment" of the logic is decidable (complexity ranges from PSPACE to EXPSPACE). The fragment can express the program logics of straight-line string-manipulating programs with concatenations and transductions as atomic operations, which arise when performing bounded model checking or dynamic symbolic executions. We demonstrate that the logic can naturally express constraints required for analysing mutation XSS in web applications. Finally, the logic remains decidable in the presence of length, letter counting, regular, indexOf, and disequality constraints.
Black-box vulnerability scanners can miss a non-negligible portion of vulnerabilities. This is true even for cross-site scripting (XSS) vulnerabilities, which are relatively simple to spot. In this paper, we focus on this vulnerability class, and systematically explore 6 black-box scanners to uncover how they detect XSS vulnerabilities, and obtain useful insights to understand their limitations and design better detection methods. A novelty of our workflow is the retrofitting of the testbed so as to accommodate payloads that triggered no vulnerabilities in the initial set. This has the benefit of creating a systematic process to increase the number of test cases, which was not considered by previous testbed-driven approaches.
Cross-Site Scripting (XSS) — around fourteen years old vulnerability is still on the rise and a continuous threat to the web applications. Only last year, 150505 defacements (this is a least, an XSS can do) have been reported and archived in Zone-H (a cybercrime archive) (http://www.zone-h.org/). The online WYSIWYG (What You See Is What You Get) or rich-text editors are now a days an essential component of the web applications. They allow users of web applications to edit and enter HTML rich text (i.e., formatted text, images, links and videos etc.) inside the web browser window. The web applications use WYSIWYG editors as a part of comment functionality, private messaging among users of applications, blogs, notes, forums post, spellcheck as-you-type, ticketing feature, and other online services. The XSS in WYSIWYG editors is considered more dangerous and exploitable because the user-supplied rich-text contents (may be dangerous) are viewable by other users of web applications.
The security gateway between an attacker and a user's private data is the Cloud Control Interface (CCI): If an attacker manages to get access to this interface, he controls the data. Several high-level data breaches originate here, the latest being the business failure of the British company Code Spaces. In such situations, using a private cloud is often claimed to be more secure than using a public cloud. In this paper, we show that this security assumption may not be justified: We attack private clouds through their rich, HTML5-based control interfaces, using well-known attacks on web interfaces (XSS, CSRF, and Clickjacking) combined with novel exploitation techniques for Infrastructure as a Service clouds.
We analyzed four open-source projects for private IaaS cloud deployment (Eucalyptus, OpenNebula, OpenStack, and openQRM) in default configuration. We were able to compromise the security of three cloud installations (Eucalyptus, OpenNebula, and openQRM) One of our attacks (OpenNebula) allowed us to gain root access to VMs even if full perimeter security is enabled, i.e. if the cloud control interface is only reachable from a certain segment of the company's network, and if all network traffic is filtered through a firewall.
We informed all projects about the attack vectors and proposed mitigations. As a general recommendation, we propose to make web management interfaces for private clouds inaccessible from the Internet, and to include this technical requirement in the definition of a private cloud.
Many cloud-based services offer interfaces to Single Sign-On (SSO) systems. This helps companies and Internet users to keep control over their data: By using an Identity Provider (IdP), they are able to enforce various access control strategies (e.g., RBAC) on data processed in the cloud.
On the other hand, IdPs provide a valuable single point of attack: If the IdP can be compromised, all cloud services are affected, including well-protected applications such as Google Apps and Salesforce. This increases the impact of the attack by several orders of magnitude.
In this paper, we analyze the security of six real-world SAML-based IdPs (OneLogin, Okta, WSO2 Stratos, Cloudseal, SSOCircle, and Bitium) which are used to protect cloud services. We present a novel attack technique (ACS Spoofing), which allows the adversary to successfully impersonate the victim in four of these SSO systems. To complete our survey on IdP security, we additionally evaluated the security of these six IdPs against well-known web attacks, and we were successful against four of them. In summary, we were able to break all six SSO systems.
We present a online penetration test tool, ACSScanner, which is able to detect ACS Spoofing vulnerabilities on arbitrary IdPs. Additionally, we discuss several countermeasures for each attack type, ranging from simple whitelisting to the signing of authentication requests, and from anti-CSRF tokens and HTTP-Only cookies to cookie-TLS-bindings. We have implemented a combination of two advanced countermeasures.
Due to the portability advantage, HTML5-based mobile apps are getting more and more popular. Unfortunately, the web technology used by HTML5-based mobile apps has a dangerous feature, which allows data and code to be mixed together, making code injection attacks possible. In this paper, we have conducted a systematic study on this risk in HTML5-based mobile apps. We found a new form of code injection attack, which inherits the fundamental cause of Cross-Site Scripting attack (XSS), but it uses many more channels to inject code than XSS. These channels, unique to mobile devices, include Contact, SMS, Barcode, MP3, etc. To assess the prevalence of the code injection vulnerability in HTML5-based mobile apps, we have developed a vulnerability detection tool to analyze 15,510 PhoneGap apps collected from Google Play. 478 apps are flagged as vulnerable, with only 2.30% false-positive rate. We have also implemented a prototype called NoInjection as a Patch to PhoneGap in Android to defend against the attack.
Browser extensions have a great role in bringing changes to the web browser behavior and improving browser performance. However, nowadays, many browser extensions fail to meet the security requirements. Due to this, they become a medium for various attackers to steal the credential information of the users. The proposal in this paper makes a pitch for the protection of an augmented browser extension against mutation-based cross-site scripting attack. A method is introduced for hardening the browser extension script along with dead code injection. A mutation-based cross-site scripting identifier to identify the attacks that affect the extensions is also discussed in this paper. These methods will protect browser extensions from various malicious script injection attacks.
Due to their high practical impact, Cross-Site Scripting (XSS) attacks have attracted a lot of attention from the security community members. In the same way, a plethora of more or less effective defense techniques have been proposed, addressing the causes and effects of XSS vulnerabilities. NoScript, and disabling scripting code in non-browser applications such as e-mail clients or instant messengers.
As a result, an adversary often can no longer inject or even execute arbitrary scripting code in several real-life scenarios.
In this paper, we examine the attack surface that remains after XSS and similar scripting attacks are supposedly mitigated by preventing an attacker from executing JavaScript code. We address the question of whether an attacker really needs JavaScript or similar functionality to perform attacks aiming for information theft. The surprising result is that an attacker can also abuse Cascading Style Sheets (CSS) in combination with other Web techniques like plain HTML, inactive SVG images or font files. Through several case studies, we introduce the so called scriptless attacks and demonstrate that an adversary might not need to execute code to preserve his ability to extract sensitive information from well protected websites. More precisely, we show that an attacker can use seemingly benign features to build side channel attacks that measure and exfiltrate almost arbitrary data displayed on a given website.
We conclude this paper with a discussion of potential mitigation techniques against this class of attacks. In addition, we have implemented a browser patch that enables a website to make a vital determination as to being loaded in a detached view or pop-up window. This approach proves useful for prevention of certain types of attacks we here discuss.
As social networking sites proliferate across the World Wide Web, complex user-created HTML content is rapidly becoming the norm rather than the exception. User-created Web content is a notorious vector for cross-site scripting (XSS) attacks that target Web sites and confidential user data. In this threat climate, mechanisms that render web applications immune to XSS attacks have been of recent research interest.A challenge for these security mechanisms is enabling Web applications to accept complex HTML input from users, while disallowing malicious script content. This challenge is made difficult by anomalous Web browser behaviors, which are often used as vectors for successful XSS attacks.Motivated by this problem, we present a new XSS defense strategy designed to be effective in widely deployed existing Web browsers, despite anomalous browser behavior. Our approach seeks to minimize trust placed on browsers for interpreting untrusted content. We implemented this approach in a tool called Blueprint that was integrated with several popular Web applications. We evaluated Blueprint against a barrage of stress tests that demonstrate strong resistance to attacks, excellent compatibility with Web browsers and reasonable performance overheads.
JavaScript-based malware attacks have increased in recent years and currently represent a significant threat to the use of desktop computers, smartphones, and tablets. While static and runtime methods for malware detection have been proposed in the literature, both on the client side, for just-in-time in-browser detection, as well as offline, crawler-based malware discovery, these approaches encounter the same fundamental limitation. Web-based malware tends to be environment-specific, targeting a particular browser, often attacking specific versions of installed plugins. This targeting occurs because the malware exploits vulnerabilities in specific plugins and fails otherwise. As a result, a fundamental limitation for detecting a piece of malware is that malware is triggered infrequently, only showing itself when the right environment is present. We observe that, using fingerprinting techniques that capture and exploit unique properties of browser configurations, almost all existing malware can be made virtually impossible for malware scanners to detect. This paper proposes ROZZLE, a JavaScript multi-execution virtual machine, as a way to explore multiple execution paths within a single execution so that environment-specific malware will reveal itself. Using large-scale experiments, we show that ROZZLE increases the detection rate for offline runtime detection by almost seven times. In addition, ROZZLE triples the effectiveness of online runtime detection. We show that ROZZLE incurs virtually no runtime overhead and allows us to replace multiple VMs running different browser configurations with a single ROZZLE-enabled browser, reducing the hardware requirements, network bandwidth, and power consumption.
We empirically analyzed sanitizer use in a shipping web application with over 400,000 lines of code and over 23,244 methods, the largest empirical analysis of sanitizer use of which we are aware. Our analysis reveals two novel classes of errors: context-mismatched sanitization and inconsistent multiple sanitization. Both of these arise not because sanitizers are incorrectly implemented, but rather because they are not placed in code correctly. Much of the work on crosssite scripting detection to date has focused on finding missing sanitizers in programs of average size. In large legacy applications, other sanitization issues leading to cross-site scripting emerge. To address these errors, we propose ScriptGard, a system for ASP.NET applications which can detect and repair the incorrect placement of sanitizers. ScriptGard serves both as a testing aid to developers as well as a runtime mitigation technique. While mitigations for cross site scripting attacks have seen intense prior research, we consider both server and browser context, none of them achieve the same degree of precision, and many other mitigation techniques require major changes to server side code or to browsers. Our approach, in contrast, can be incrementally retrofitted to legacy systems with no changes to the source code and no browser changes. With our optimizations, when used for mitigation, ScriptGard incurs virtually no statistically significant overhead.
While most research on XSS defense has focused on techniques for securing existing applications and re-architecting browser mechanisms, sanitization remains the industry-standard defense mechanism. By streamlining and automating XSS sanitization, web application frameworks stand in a good position to stop XSS but have received little research attention. In order to drive research on web frameworks, we systematically study the security of the XSS sanitization abstractions frameworks provide. We develop a novel model of the web browser and characterize the challenges of XSS sanitization. Based on the model, we systematically evaluate the XSS abstractions in 14 major commercially-used web frameworks. We find that frameworks often do not address critical parts of the XSS conundrum. We perform an empirical analysis of 8 large web applications to extract the requirements of sanitization primitives from the perspective of realworld applications. Our study shows that there is a wide gap between the abstractions provided by frameworks and the requirements of applications.
Content sniffing attacks occur if browsers render non-HTML files embedded with malicious HTML contents or JavaScript code as HTML files. The rendering of these embedded contents might cause unwanted effects such as the stealing of sensitive information through the execution of malicious JavaScript code. The primary source of these attacks can be stopped if the uploading of malicious files can be prevented from the server side. However, existing server side content sniffing attack detection approaches suffer from a number of limitations. First, file contents are checked only to a fixed amount of initial bytes whereas attack payloads might reside anywhere in the file. Second, these approaches do not provide any mechanism to assess the malicious impact of the embedded contents on browsers. This paper addresses these issues by developing a server side content sniffing attack detection mechanism based on content analysis using HTML and JavaScript parsers and simulation of browser behavior via mock download testing. We have implemented our approach in a tool that can be integrated in web applications written in various languages. In addition, we have developed a benchmark suite for the evaluation purpose that contains both benign and malicious files. We have evaluated our approach on three real world PHP programs suffering from content sniffing vulnerabilities. The evaluation results indicate that our approach can secure programs against content sniffing attacks by successfully preventing the uploading of malicious files.
The majority of all security problems in today's Web applications is caused by string-based code injection, with Cross-site Scripting (XSS)being the dominant representative of this vulnerability class. This thesis discusses XSS and suggests defense mechanisms. We do so in three stages: First, we conduct a thorough analysis of JavaScript's capabilities and explain how these capabilities are utilized in XSS attacks. We subsequently design a systematic, hierarchical classification of XSS payloads. In addition, we present a comprehensive survey of publicly documented XSS payloads which is structured according to our proposed classification scheme. Secondly, we explore defensive mechanisms which dynamically prevent the execution of some payload types without eliminating the actual vulnerability. More specifically, we discuss the design and implementation of countermeasures against the XSS payloads Session Hijacking'', Cross-site Request Forgery'', and attacks that target intranet resources. We build upon this and introduce a general methodology for developing such countermeasures: We determine a necessary set of basic capabilities an adversary needs for successfully executing an attack through an analysis of the targeted payload type. The resulting countermeasure relies on revoking one of these capabilities, which in turn renders the payload infeasible. Finally, we present two language-based approaches that prevent XSS and related vulnerabilities: We identify the implicit mixing of data and code during string-based syntax assembly as the root cause of string-based code injection attacks. Consequently, we explore data/code separation in web applications. For this purpose, we propose a novel methodology for token-level data/code partitioning of a computer language's syntactical elements. This forms the basis for our two distinct techniques: For one, we present an approach to detect data/code confusion on run-time and demonstrate how this can be used for attack prevention. Furthermore, we show how vulnerabilities can be avoided through altering the underlying programming language. We introduce a dedicated datatype for syntax assembly instead of using string datatypes themselves for this purpose. We develop a formal, type-theoretical model of the proposed datatype and proof that it provides reliable separation between data and code hence, preventing code injection vulnerabilities. We verify our approach's applicability utilizing a practical implementation for the J2EE application server.
Internet Explorer 8 implements an anti Cross-site Scripting (XSS) mechanism to detect certain types of XSS attacks. This feature can be abused by attackers in order to enable XSS on web sites and web pages that would otherwise be immune to XSS.
Web applications often use special string-manipulating sanitizers on untrusted user data, but it is difficult to reason manually about the behavior of these functions, leading to errors. For example, the Internet Explorer cross-site scripting filter turned out to transform some web pages without JavaScript into web pages with valid Java-Script, enabling attacks. In other cases, sanitizers may fail to commute, rendering one order of application safe and the other dangerous. BEK is a language and system for writing sanitizers that enables precise analysis of sanitizer behavior, including checking idempotence, commutativity, and equivalence. For example, BEK can determine if a target string, such as an entry on the XSS Cheat Sheet, is a valid output of a sanitizer. If so, our analysis synthesizes an input string that yields that target. Our language is expressive enough to capture real web sanitizers used in ASP.NET, the Internet Explorer XSS Filter, and the Google AutoEscape framework, which we demonstrate by porting these sanitizers to BEK. Our analyses use a novel symbolic finite automata representation to leverage fast satisfiability modulo theories (SMT) solvers and are quick in practice, taking fewer than two seconds to check the commutativity of the entire set of Internet Exporer XSS filters, between 36 and 39 seconds to check implementations of HTMLEncode against target strings from the XSS Cheat Sheet, and less than ten seconds to check equivalence between all pairs of a set of implementations of HTMLEncode. Programs written in BEK can be compiled to traditional languages such as JavaScript and C#, making it possible for web developers to write sanitizers supported by deep analysis, yet deploy the analyzed code directly to real applications.
Cross-site scripting (XSS) vulnerabilities are among the most common and serious web application vulnerabilities. It is challenging to eliminate XSS vulnerabilities because it is difficult for web applications to sanitize all user input appropriately. We present Noncespaces, a technique that enables web clients to distinguish between trusted and untrusted content to prevent exploitation of XSS vulnerabilities. Using Noncespaces, a web application randomizes the the (X)HTML tags and attributes in each document before delivering it to the client. As long as the attacker is unable to guess the random mapping, the client can distinguish between trusted content created by the web application and untrusted content provided by an attacker. To implement Noncespaces with minimal changes to web applications, we leverage a popular web application architecture to automatically apply Noncespaces to static content processed through a popular PHP template engine. We design a policy language for Noncespaces, implement a training mode to assist policy development, and conduct extensive security testing of a generated policy for two large web applications to show the effectiveness of our technique.
We address the challenge of building secure embedded web interfaces by proposing WebDroid: the first frame-work specifically dedicated to this purpose. Our design extends the Android Framework, and enables developers to create easily secure web interfaces for their applica-tions. To motivate our work, we perform an in-depth study of the security of web interfaces embedded in consumer electronics devices, uncover significant vulnerabilities in all the devices examined, and categorize the vulnerabili-ties. We demonstrate how our framework's security mech-anisms prevent embedded applications from suffering the vulnerabilities exposed by our audit. Finally we evaluate the efficiency of our framework in terms of performance and security.
Many Web sites such as MySpace, Facebook and Twitter allow their users to upload files. However when a Web site's Content-Sniffing algorithm differs from a browser's Content-Sniffing algorithm, an attacker can often mount a Content-Sniffing XSS attack on the visitor. That is, by carefully embedding HTML code containing malicious script into a non-HTML file and uploading this file to the Web site, an attacker can deceive the visitor's browser into assuming the file as HTML file and run the script code. However Content-Sniffing XSS attack can be avoided if files uploaded on the server are checked for HTML codes. In this paper we propose a server-side ingress filter that aims to protect vulnerable browsers which may treat non-HTML files as HTML files. Our filter examines user-uploaded files against a set of potentially dangerous HTML elements (a set of regular expressions). The results of our experiment show that the proposed automata-based scheme is highly efficient and more accurate than existing signature-based approach.
Cross-site scripting (or XSS) has been the most dominant class of web vulnerabilities in 2007. The main underlying reason for XSS vulnerabilities is that web markup and client-side languages do not provide principled mechanisms to ensure secure, ground-up isolation of user-generated data in web application code. In this paper, we develop a new approach that combines randomization of web application code and runtime tracking of untrusted data both on the server and the browser to combat XSS attacks. Our technique ensures a fundamental integrity property that prevents untrusted data from altering the structure of trusted code throughout the execution lifetime of the web application. We call this property document structure integrity (or DSI). Similar to prepared statements in SQL, DSI enforcement ensures automatic syntactic isolation of inline usergenerated data at the parser-level. This forms the basis for confinement of untrusted data in the web browser based on a server-specified policy. We propose a client-server architecture that enforces document structure integrity in a way that can be implemented in current browsers with a minimal impact to compatibility and that requires minimal effort from the web developer. We implemented a proof-of-concept and demonstrated that such DSI enforcement with a simple default policy is sufficient to defeat over 98 % of the 5,328 real-world reflected XSS vulnerabilities documented in 2007, with very low performance overhead both on the client and server. 1
This paper focuses on defense mechanisms,for cross-site scripting at- tacks, the top threat on web applications today. It is believed that input validation (or filtering) can effectively prevent XSS attacks on the server side. In this pa- per, we discuss several recent real-world XSS attacks and analyze the reasons for the failure of filtering mechanisms,in defending these attacks. We conclude that while filtering is useful as a first level of defense against XSS attacks, it is ineffective in preventing several instances of attack, especially when user input includes content-rich HTML. We then propose XSS-GUARD, a new framework that is designed to be a prevention mechanism,against XSS attacks on the server side. XSS-GUARD works by dynamically,learning the set of scripts that a web application intends to create for any HTML request. Our approach also includes a robust mechanism,for identifying scripts at the server side and removes any script in the output that is not intended by the web application. We discuss extensive ex- perimental results that demonstrate the resilience of XSS-GUARD in preventing a number,of real-world XSS exploits. Keywords: Cross-site scripting (XSS), Attack Prevention, Filtering, Security
Cross-site scripting flaws have now surpassed buffer overflows as the world's most common publicly-reported security vulnerability. In recent years, browser vendors and researchers have tried to develop client-side filters to mitigate these attacks. We analyze the best existing filters and find them to be either unacceptably slow or easily circumvented. Worse, some of these filters could introduce vulnerabilities into sites that were previously bug-free. We propose a new filter design that achieves both high performance and high precision by blocking scripts after HTML parsing but before execution. Compared to previous approaches, our approach is faster, protects against more vulnerabilities, and is harder for attackers to abuse. We have contributed an implementation of our filter design to the WebKit open source rendering engine, and the filter is now enabled by default in the Google Chrome browser.
Cross-site scripting defenses often focus on HTML doc- uments, neglecting attacks involving the browser's content- sniffing algorithm, which can treat non-HTML content as HTML. Web applications, such as the one that manages this conference, must defend themselves against these attacks or risk authors uploading malicious papers that automatically submit stellar self-reviews. In this paper, we formulate content-sniffing XSS attacks and defenses. We study content- sniffing XSS attacks systematically by constructing high- fidelity models of the content-sniffing algorithms used by four major browsers. We compare these models with Web site content filtering policies to construct attacks. To de- fend against these attacks, we propose and implement a principled content-sniffing algorithm that provides security while maintaining compatibility. Our principles have been adopted, in part, by Internet Explorer 8 and, in full, by Google Chrome and the HTML 5 working group.
swfobject -SWFObject is an easy-to-use and standards-friendly method to embed Flash content, which utilizes one small JavaScript file
- B Van
B. van der Sluis. swfobject -SWFObject is an easy-to-use and standards-friendly method to embed Flash content, which utilizes one small JavaScript file. http://code.google.com/p/swfobject/.
CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests
- Cert Org
CERT.org. CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests. http://www.cert.org/advisories/CA-2000-02.html, 2012.
The Anatomy of Cross Site Scripting. Hitchhiker's World
- G Zuchlinski
G. Zuchlinski. The Anatomy of Cross Site Scripting. Hitchhiker's World, 8, Nov. 2003.
Dom parsing and serialization (w3c editor's draft 07 november 2012)
- T Leithead
T. Leithead. Dom parsing and serialization (w3c editor's draft 07 november 2012). http://dvcs.w3. org/hg/innerhtml/raw-file/tip/index.html.
Bug 29278: XSSAuditor bypasses from sla.ckers.org
- A Barth
A. Barth. Bug 29278: XSSAuditor bypasses from sla.ckers.org. https://bugs.webkit.org/show_bug.cgi?id=29278.
HTML Purifier CSS quoting full disclosure
- E Z Yang
E. Z. Yang. HTML Purifier CSS quoting full disclosure. http://htmlpurifier.org/, Sept. 2010.
Issue 43902: innerHTML decompilation issues in textarea
- E Vela
E. Vela. Issue 43902: innerHTML decompilation issues in textarea. http://code.google.com/p/chromium/ issues/detail?id=43902.
The Tangled Web: A Guide to Securing Modern Web Applications
- M Zalewski
M. Zalewski. The Tangled Web: A Guide to Securing Modern Web Applications. No Starch Press, 2011.
Technical explanation of The MySpace Worm
- S Kamkar
S. Kamkar. Technical explanation of The MySpace Worm.
DOM Based Cross Site Scripting or XSS of the Third Kind
- A Klein
A. Klein. DOM Based Cross Site Scripting or XSS of the Third Kind. Web Application Security Consortium, 2005.
IE8 XSS Filter design philosophy in-depth. http://blogs.msdn.com/b/dross/archive-xss-filter-design-philosophy-in-depth.aspx
- D Ross