- "However, if developers do not use the security features of the primitive fully or implicitly trust data arriving on this channel , a variety of attacks can result"
- "We observe a common problem with these new clientside primitives: to ensure security, every use of the primitive needs to be accompanied by custom sanity checks"
- "We propose the economy of liabilities principle in designing security primitives—a primitive must minimize the liability that the user undertakes to ensure application security." For example, in this context, the principle of economy of liabilities implies that client-side primitives should internally perform sanitization functionality critical to achieve the intended security property, as much as possible. New primitives today ignore this design principle, achieving security only ‘in principle’ rather than ‘in practice’
- "In particular, we suggest a declarative style, whitelist-based origin validation scheme that should be provided by the postMessage primitive and enforced by the browser to ensure channel integrity"
- "For client-side database primitives, we suggest the browser database interface should automatically perform output sanitization to prevent persistent XSS attacks"
- "Web browsers typically prevent documents with different origins from affecting each other
"
- "Note that this message exchange happens completely over the client side and no data is sent over the network.
"
- "The intended recipient’s origin, specified in the method call, is called the targetOrigin parameter. For use cases in which confidentiality is not essential, a sender can specify the all-permissive ‘*’ literal as the targetOrigin
"
- "The recipient is expected to validate the sender’s origin as coming from a trusted source, thus achieving sender authenticity
"
- "We conjecture that for complex cross-domain interactions involving fine-grained origins, developers may fail to follow the recommended practice
"
- "Due to the complexity of the JavaScript code used by these protocols, we use the Kudzu [10] system to check for the absence of such validation in the code
"
- "An attacker can assume the user to have already logged onto Facebook and authorized Facebook Connect applications not controlled by the attacker
"
- "At the end of this transaction, the user has essentially logged in to implementor using his Facebook credentials.
"
- "As discussed before, validating the origin of received messages is necessary for ensuring sender authenticity.
"
- "In this particular case, we find that the data received over the channel is used in a code evaluation construct and thus allows an attacker to inject arbitrary code into implementor’s security context.
"
- "On our test site, we were able to inject a script payload into the benign implementor’s security context3
"
- "Setting the targetOrigin parameter to the ‘*’ literal leaks sensitive user data like profile information and friend lists to the attacker.
"
- "As a result, validating the origin becomes nontrivial. Additionally, for complex protocols, these checks must be repeated for every message
"
- "In fact, in our discussion with Facebook, we were informed that they used the all-permissive ‘*’ directive because postMessage does not support multicast and implementing this functionality would require a series of string-based verification comparisons
"
- "The use of the all-permissive ‘*’ as the targetOrigin allows leakage of confidential data
"
- "We find that data stored in client-side databases is often used in code evaluation constructs without sanitization.
"
- "Client-side databases, thus, provide additional avenues for attackers to persist their payloads across sessions. For instance, attackers only need to inject XSS attack payloads once into the client-side storage to have them repeatedly compromise the client-side code integrity for sustained periods of time (unlike a common reflected XSS issue which is fixed once patched). Additionally, because the attack payload is stored on the client-side, the server is oblivious to the nefarious activity
"
- "localStorage is a key/value store tied to an application’s origin. Script executing within an origin can get or set values of the data store using the localStorage object"
- "The goal of either attacker is to inject code into the local storage in order to gain a persistent foothold in the application" application—one that remains even when the transient attack vector is fixed. Once an application has been compromised, the attacker has control of the application until the client side database is cleared
- "As a second attack vector, suppose that an attacker has exploited a transient XSS vulnerability as a primary attack vector and has been able to execute arbitrary code within the context of the target site. The attacker is able to modify the database arbitrarily because the attacker has used the XSS to execute JavaScript with the same privilege as the code running within that origin. Not only is this attack persistent, it is also stealthy"
- "In such a case, the attacker writes an exploit such that its payload is stored inside an email in the database. When the user views the email, the injected code is executed. Now, even if the XSS vulnerability is fixed, the payload persists as long as the database."
- "We evaluated 11 applications that use client-side storage using Kudzu. Kudzu, a systematic vulnerability finding tool built on the WebKit framework, is a dynamic symbolic execution engine framework which is designed to analyze JavaScript applications running in browsers"
- "When using Translate, the result of a translation is placed into a text node on the user’s page. Therefore, the attack is mitigated as no code can be executed in a text node."
- However, all of the other applications failed to sufficiently sanitize database outputs. We speculate that some applications did not sanitize database outputs because of the complexity of the sanitization process required to eliminate the attack.
- "Based on the current usage, in order to ensure authenticity of messages received, we suggest a declarative system for specifying origins allowed to send messages will function better than manual origin checks. For instance, the Content Security Policy proposal allows a website to specify a whitelist of origins trusted to execute code in the website’s security context [7]. We suggest extending CSP with a directive to specify origins allowed to send messages to the website"
- "But, like postMessage, we noticed that the output sanitization can often be complex and occur throughout the application code."
- "They added that they felt, to a large extent, that these problems were inherent to the way that the mechanisms such as localStorage were designed and that first-degree XSS attacks are their primary focus."
- "In the case of postMessage, we reverse engineered the client-side protocols and systematically extracted the security-relevant checks in the code to find new vulnerabilities in them."
- "In the case of client-side storage, we found that applications do not sanitize database outputs, which can lead to a stealthy, persistent, client-side XSS attack."