========= pMForce =========

1. "While the Same-Origin Policy prevents direct data exchange with documents from other origins, the postMessage API offers one relaxation that allows developers to exchange data across these boundaries."
2. "To achieve this goal, we present an automated analysis framework running inside the browser, which uses selective forced execution paired with lightweight dynamic taint tracking to find traces in the analyzed handlers that end in sinks allowing for code execution or state alterations."
3. "Based on these constraints, we use Z3 to generate postMessages aimed at triggering the insecure functionality to prove exploitability, and validate our findings at scale."
4. "The web that we know today heavily relies on the intricate interplay of various services that jointly contribute to the plethora of feature-rich applications that we have grown fond of over the years. This interconnectivity, however, would not be possible without controlled relaxations of the web’s fundamental security principle, i.e., the Same-Origin Policy (SOP)."
5. "The receiving frame can register JavaScript callback functions that are invoked when a postMessage is dispatched to the current frame. The postMessage API provides the means to ascertain the integrity and confidentiality of messages. However, these mechanisms are purely optional."
6. "In various cases, these handlers could be abused to achieve Cross- Site Scripting (XSS), which allows an attacker to exfiltrate data and perform actions on behalf of the user."
7. "integrity is enforced by checking that the message originates from https://bar.org before executing our intended functionality. Confidentiality is achieved by fixing the second parameter of the postMessage call to the desired destination origin."
8. "Our work aims at automatically finding security- and privacy-sensitive functionalities inside such handlers, which can be exploited using standard attacker models, i.e., the web attacker"
9. "We are interested in understanding how many handlers conduct security- and privacy-sensitive behavior that can be used across origins. In particular, out of this set of sites, we want to investigate how many of those could be abused by an attacker, e.g., because they lack proper integrity checks, to compromise the site"
10. "By using an SMT solver on the path constraints extracted from these traces, we can generate postMessages that trigger the dangerous behavior"
11. "However, such two frames might need to exchange data to allow users a seamless integration of services, e.g., a website using a third-party payment provider that handles the billing of the customer"
12. "In the setting of postMessages, one frame sends a postMessage containing arbitrary, serializable data to another frame by calling the postMessage functionality on a handle to the other frame."
13. In various cases, these handlers could be abused to achieve Cross-Site Scripting (XSS), which allows an attacker to exfiltrate data and perform actions on behalf of the user. Besides introducing XSS, postMessage handlers can be abused to manipulate client-side state (such as cookies and localStorage) or leak the very same state to attackers.
14. "By using an SMT solver on the path constraints extracted from these traces, we can generate postMessages that trigger the dangerous behavior. Furthermore, we augment our traces by encoding exploitation criteria on the data flows, allowing us to generate exploit candidates, which we validate automatically"
15. "In fact, our crawls show that among the top 100,000 sites we can find over 27,000 hash-unique handlers. Given this widespread usage of postMessages, we can no longer meaningfully rely on manual efforts to reason about the state of postMessage handler security."
16. "To enable such use cases, the postMessage API was introduced to allow for controlled relaxations of the SOP. In the setting of postMessages, one frame sends a postMessage containing arbitrary, serializable data to another frame by calling the postMessage functionality on a handle to the other frame."
17. "Our related work is mainly distributed among two axes, the first one being the feasibility of applying advanced program analysis techniques such as forced execution and concolic execution to web sites"
18. "We purposely chose forced execution over symbolic execution, as our approach only needs to conduct the costly constraint solving step when we have found an interesting trace in the program, as we are only interested in a small subset of all behavior constituting a normal postMessage handler."
19. "With respect to XSS on the client, plenty of research has been conducted on the feasibility of finding client-side XSS at scale [10, 14, 25] by using a browser engine with byte-level taint tracking and context-sensitive exploit generation schemes ."
20. "We further show that the 2013 insight that even if postMessage handlers perform origin checks, most of them are faulty and circumventable by an attacker, are no longer valid."
21. "We use the puppeteer Node.js framework to steer our instances of Chromium."
22. "All the modules,except for the constraint solving routine, are implemented in Javascript, which allows us to perform most of the necessary operation within the browser itself."
23. "As there exists no stable port of Z3 for Javascript, we implemented our constraint solving mechanism in python using Z3Py, which is exposed to the other modules via bindings through the Dev Tools protocol, thus accessible through the window object."
24. "To that end, we introduce the concept of Exploit Templates and utilize those together with the path constraints found in the traces to generate exploit candidates using Z3 as an SMT solver."
25. "To achieve this goal, we utilize the dynamic instrumentation framework Iroh [13] and extend its capabilities where necessary."
26. "As a final control flow altering step, we change the outcome of any expression that is lazily evaluated, i.e., if an OR is lazily evaluated, we change the value of the first expression to false and if an AND is lazily executed we change the value to true"
27. "While the forced execution allows us to reach interesting parts of the handler functionality, we still need to discuss how we can leverage it to find traces that are relevant to the security or privacy of the site"
28. "so-called XSS polyglots [2]. These are payloads intended to break out of as many contexts as possible, before adding pieces of HTML code that then execute the XSS payload"
29. "To paint a clear picture of how many different families of handlers we could observe to be vulnerable, we used a hash over the lexical structure, i.e., the representation as tokens, of the registered handlers and used this as a distinguishing facto"
30. "Naturally, this analysis comes with the inherent limitation that we do not have any means to log in to the sites. While this is a general limitation of a large-scale analysis, our framework could be used in a context where automatic logins are feasible, e.g., assisted by login information of the developer. This would allow us to uncover more functionality of the sites overall, but in particular, could unveil more handler functions which handle sensitive user data since these might only be present after the login."
31. ""
32. ""
33. ""
34. ""
35. ""
36. ""
37. ""