========= Don’t Trust The Locals =========

1. "... we leverage taint tracking to identify suspicious flows from client-side persistent storage (Web Storage, cookies) to dangerous sinks (HTML, JavaScript, and script.src)"
2. "a Web Attacker who can leverage flows into storage or an existing reflected XSS flaw to persist their payload."
3. "We find that more than 8% of them have unfiltered data flows from persistent storage to a dangerous sink"
4. "With our taint-aware browser and these models in mind, we study the prevalence of Persistent Client-Side XSS in the Alexa Top 5,000 domains."
5. "We find that more than 8% of them have unfiltered data flows from persistent storage to a dangerous sink " Cross-Site Scripting enabled by persistence APIs on the client has not been acknowledged as an important type of XSS
6. "we investigate the risk of using data from client-side storage in JavaScript, showing that Persistent Client-Side XSS must, in fact, be considered as a real threat to modern Web applications.""
7. "We leverage taint tracking in the browser to find exploitable flows of data from Web Storage or cookies to dangerous sinks, such as eval. "
8. "Cookies are widely used for session management when sites offer a login and for tracking purposes, but are also often used to store preferences, such as the selected language."
9. "Considering a Network Attacker capable of temporarily hijacking a non-encrypted connection, and a regular Web Attacker capable of forcing her victims to visit arbitrary URLs"
10. "These simple key-value stores are used by browsers to persist small pieces of string data, which are sent along in every HTTP request to matching servers. This allows sites to overcome the inherent limitation of HTTP, i.e., the lack of state."
11. "... introduced the Web Storage API. It consists of two containers, namely Session and Local Storage. While the former only persists data for the duration of a browsing session and is unique for each window, Local Storage makes it possible to indefinitely persist data on the client."
12. Unlike cookies, Web Storage is bound to an origin.
13. "The most basic security policy in browsers it the SameOrigin Policy [67]. This policy governs interactions between sites, specifically as they relate to the access from JavaScript to another window. Whenever a JavaScript snippet tries to gain access to resources from another window" (e.g., popup or iframe), the action is only allowed if the accessed resource shares the origin of the JavaScript. This way, a malicious site including an iframe to another domain cannot read the content of the rendered document from that domain
14. "Cross-Site Scripting (XSS) is a code injection attack, in which an adversary is able to add JavaScript code of her choosing to a vulnerable site."
15. "In our notion, XSS can be roughly categorized in two dimensions. Specifically, it can be reflected or persistent, and can be located in the server-side or client-side code. Reflected here refers to the fact that the vulnerable code reflects back some attacker controllable information, e.g., using PHP’s echo functionality to print part of the requested URL on the server. Persistent in turn means that the malicious payload is not directly echoed back by the code, but rather stored and later retrieved."
16. "Abstractly speaking, an XSS attack occurs if some attacker controllable piece of data flows into a dangerous sink. On the client, these sinks can be classified into three categories: rendering of HTML, execution of JavaScript, and the inclusion of additional script resources"
17. "We then relate this concept to its server-side counterpart and introduce two attacker models, which enable storing payloads in her victim’s persistence APIs, allowing for a persistent XSS attack"
18. "An XSS attacker’s goal is often to hijack the session of their victim, i.e., steal the authentication cookies. This problem is mitigated by the use of http-only cookies, which ensure that cookies cannot be accessed from JavaScript and are therefore out of reach of the adversary"
19. "This attack becomes more powerful if the attacker conducts a resident XSS attack [23], which leverages the existing XSS to ensure that all links a user may visit are also XSS-infested. "
20. "If, however, the malicious payload is persisted on the client, i.e., in cookies or Local Storage, the XSS attacker’s code is revived on every subsequent load of the flawed site, even without the necessity to add the payload to, e.g., the URL"
21. "In this example, the data originating from Local Storage was passed to eval in an unfiltered manner"
22. "However, the value extracted from storage is neither checked for its format nor encoded to ensure that the extracted value cannot be abused to add additional HTML markup."
23. "Although in general, Session Storage allows to persist data on the client, it is bound to a browsing window and deleted when said window is closed."
24. "A network-level adversary is able to inject arbitrary packets into any unencrypted connection between a client and server. "
25. "Such vulnerabilities occur when an adversary’s input is not filtered or encoded before being written to persistent storage, such as a SQL database"
26. " At the same time, when the JavaScript code causing the vulnerable flow from storage to sink is included in every page of a domain, a single injection means that regardless of which URL on the domain is visited, the attack succeeds (assuming the JavaScript snippet causing the flow is included)."
27. "Cookies can be manipulated either by setting them in the faked HTTP response, or by delivering JavaScript code which achieves the same"
28. " The ability to inject arbitrary cookies is hindered by HTTP Strict Transport Security (abbreviated HSTS) [22]. This HTTP header ensures that a site will only be accessible via HTTPS."
29. "On top of this, we build a crawling extension, which recursively crawls a given domain, and reports all found data flows to a database."
30. "Our engine is based on Chromium and is capable of attaching taint information to strings. Moreover, uall JavaScript string operations (e.g., concatenation or substrings) as well as the built-in encoding functions like escape pass on the taint. We taint all values from relevant sources (e.g., Local Storage and cookies). We modified Chromium to report invocations with tainted data to numerous sinks. Specifically, this includes all sinks which allow for creation of HTML (e.g., document.write or innerHTML, execution of JavaScript code (e.g., eval) as well as adding additional script resources (via script.src). Apart from these flows which might lead to a direct JavaScript execution, the engine also collects those flows that end in a persistent storage, specifically cookies and Local Storage. On top of this, we build a crawling extension, which recursively crawls a given domain, and reports all found data flows to a database."
31. "Specifically, the attacker carefully crafts the URL such that the existing reflected XSS vulnerability is triggered. The injected code, which runs in the origin of the vulnerable site, now puts the desired payload into storage (3)"
32. "To craft an exploit, our original approach would generate a sequence which breaks out of the existing context and subsequently calls some function, e.g., alert."
33. "Besides the collection of relevant flows, our crawling extension iterates over all cookies and all elements in Local Storage."
34. "In order to determine how many of these flows could, in fact, be exploited, we first determined how many domains would be attackable by an unlimited adversary, i.e., an adversary capable of modifying cookies or Local Storage for arbitrary origins. To that end, we used a Chrome extension to first visit each URL in question, modify the storage accordingly, and reload the site"
35. " First, since cookies are sent along to the server in every HTTP request, they are subject to inspection by deployed Web Application Firewalls (WAFs). Although we did not specifically record when a page was not loaded due to our cookies containing JavaScript or HTML markup, sampling sites on which our payload had not triggered frequently led to error pages clearly caused by WAFs"
36. For us, however, not all these domains are of interest, as we focus on those domains that have at least one unencoded flow from the persistence APIs to a sink
37. by an unlimited adversary, i.e., an adversary capable of modifying cookies or Local Storage for arbitrary origins.
38. In our experiments, we found this to have two reasons. First, since cookies are sent along to the server in every HTTP request, they are subject to inspection by deployed Web Application Firewalls (WAFs) .
39. "Considering the Network Attacker, we found that 293 of the 418 domains would, in fact, be exploitable, either due to a complete lack of HTTPS or due to a missing or incomplete (no includeSubDomains) deployment of HSTS, which allows for an HTTP-hosted site to set cookies for its HTTPS counterpart and parents."
40. "In our study, we found the single sign-on part of a major Chinese website network to be susceptible to both a persistent and a reflected Client-Side XSS flaw. While abusing the reflected XSS could have been used to exfiltrate the cookies of the user, these were protected with the HttpOnly flag. Given the fact that the same origin also made insecure use of persisted code from Local Storage, however, rather than trying to steal the cookie, we built a proof of concept that extracted credentials from the login field right before the submission of the credentials to the server. This way, although a single session cannot be hijacked, the attacker can easily steal the credentials when these are entered by the unknowing victim"
41. "Hence, replacing eval with the browser’s native JSON capabilities is sufficient to robustly secure these cases. Indeed, a total of 81 vulnerable domains in our dataset could be fixed by simply using JSON.parse. However, eval-based JSON parsing is much more forgiving with respect to syntactical constraints compared to the browser’s fairly strict JSON parser."
42. "The most challenging pattern in our dataset consists of scenarios in which applications use the persistence mechanisms to deliberately store HTML or JavaScript code, e.g., for client-side caching purposes."
43. "In modern browsers, Service Workers [47], which were introduced as a more capable replacement of the AppCache mechanism, can be leveraged for this purpose". They allow Web sites to introduce their own custom caching and offline mechanism, which is based on JavaScript-driven interception of HTTPS requests
44. "As the Service Worker code runs completely separated from the document’s JavaScript, this functionality cannot be influenced by the Web Attacker and, as Service Workers are an HTTPS-only feature, the Network Attacker is also rendered harmless."
45. "Specifically, the W3C has proposed the Clear-Site-Data response header. This mechanism allows site operators to truncate all client-side storage and moreover shut down all JavaScript contexts to ensure that an attacker-controlled context is unable to re-poison the storage. However, making use of this mechanism regularly inevitably destroys the purpose of having client-side storage, be it code or configuration data storage."
46. "While the exploitability of flows originating from storage does not depend on the browser, the susceptibility of a site to a reflected Client-Side XSS varies between browsing engines. Specifically, Firefox automatically encodes all parts of the URL when accessed via the location object; Chrome did not do so until version 65. Since version 65, however, the auto-encoding has changed such that the URL fragment is also encoded, meaning that exploits which target an unfiltered and unmodified flow from the fragment to a sink will not be exploitable anymore"
47. "In 2015, Zheng et al. [68] analyzed the general risks associated with the lack of integrity of cookie data. Their threat model also covers a Network and Web Attacker, which allows them to find instances of session hijacking, history stealing, and even XSS flaws"
48. "Another approach to tackle the specifics of Client-Side XSS is extending the taint tracking approach from Lekies et al.[32] to the parser level. In doing so, Stock et al. [54] were able to prevent tainted values from being interpreted as code, thus stopping all previously verified cases of reflected Client-Side XSS. Extending this to storage, however, would not work, given the inability to distinguish attacker-injected payloads in the storages, resulting either in false negatives or impaired functionality. The general idea of this solution was since refactored into Trusted Types [8], which prevent undesired code flows into code executing sinks, but have yet to be introduced into browsers."
49. ""
50. ""
51. ""
52. ""
53. ""
54. ""
55. ""
56. ""
57. ""
58. ""
59. ""
60. ""
61. ""
62. ""
63. ""
64. ""
65. ""
66. ""
67. ""
68. ""
69. ""