TheThing Limitations
This page documents serveral limitations that TheThing may have, where TheHulk can perform better.
TheThing identify the clobberable sources pure statically based on the following seven patterns (Table 3).
However, their approach may result in false negatives due to the heavily variable alias used on the client-side. That said, to statically identify the property lookups on the window or ducument object require the static analysis tool correctly resolve the base object of all the property lookups which is generally a hard questions.
TODO: Add a hard case that static analysis fail to recongnize the lookuped object is window or document.
On the other side, the approach also result in false positives on the rules S2, S4 and S5 which require the analysis the definition/declaration of variable. Even the variable has been defined and used in different scripts, the excution sequence needs to observe the page loading dynamically.
Besides, the approach cannot identify the keyed property lookup where the property key name need to be computed.
The overall pipeline depends on static analysis to identify data flows from vulnerable sources to critical sinks. The role of dynamic analysis is primarily to verify these identified vulnerabilities rather than to actively discover new exploitation vectors.
However, static analysis is prone to false negatives, especially when indirect function calls are prevalent. We have observed numerous vulnerable sources within helper functions that globally retrieve properties. This code pattern challenges the static analysis tools, requiring them to scan all potential call sites of functions such as the one below. This task is non-trivial because it involves: 1/ tracking all object types and 2/ accounting for call sites that may use properties as method calls dynamically.
Obj.prototype.getLocation = () => {
return document.location
}
Unlike traditional taint-style vulnerabilities, in the context of dom clobbering, attackers inject HTML markups in the form of DOM node types during initial loading through DOM-clobberable sources, attackers must leverage toString operations to convert DOM node types into strings or other primitive types that can flow to sink functions. toString operations generally occur in two ways:
- Implicit toString call during type coercion, which can access the href attributes of
<a>and<area>tags. - Property lookups that access corresponding DOM node attributes, such as
obj.valuewhich retrieves thevalueattribute from injected DOM nodesobj.
However, it appears that TheThing does not account for toString operations during static taint analysis. Nonetheless, dynamic analysis could potentially eliminate these false positives by disproving cases with no satisfying payloads (TODO: substantiate this claim).
TODO: We should investigate TheThing's capabilities using the simple case below. There are no valid payloads that would satisfy the second line, as no DOM nodes possess a built-in method indexOf, which will inevitably trigger an error.
<html>
<body>
<script>
let a = document.location; // clobberable source
let b = a.indexof("google.com") // never satisfy thorugh injected DOM nodes
let c = document.createElement('script');
c.src = b;
document.body.append(c);
</script>
</body>
</html>
<html>
<body>
<script>
let a = document.location; // clobberable source
let c = document.createElement('script');
c.src = b; // no toString operation and will raise error in any way
document.body.append(c);
</script>
</body>
</html>
Upon receiving the clobberable sources from the static analysis, their dynamic analysis is mainly used for verification (but not to find the gadgets). That said, their dynamic analysis will generate the payload (HTML markups) based on the pattern of identified sources, and 1/ check the clobberbility of the generated payload, 2/ do dynamic taint analysis from sources to the sinks, 3/ do the forced execution if the step 2/ fails. I guess the forced execution is mainly used for passing the non-payload-related conditions.
For reference in payload generation, the authors have provided a tool available at:
https://domclob.xyz/domc_payload_generator/
This method constructs payloads solely based on the initial clobberable source, lacking the flexibility to adapt to dynamic execution paths and specific requirements (e.g., if .textContent is used, the injected node should match the expected node type or some specific attributes should be prefixed with certain value to pass the branches).
TODO: We can use the following case to prove the above statement. If thething only consider the clobberbale source, it will generate some payloads looks like: <img name="location" src="clobbered"></img>. However, the tool collects the property read on the third line, it will generate a working payload: <img name="location" src="clobbered" value="gg"></img>.
<html>
<body>
<script>
let a = document.location; // clobberable source
let c = document.createElement('script');
let d = a.getAttribute(value);
c.src = d; // no toString operation and will raise error in any way
document.body.append(c);
</script>
</body>
</html>
Below are some questions regarding how TheThing handles certain scenarios. I am currently uncertain about these aspects:
-
1/ Dataflow Triggering: How does TheThing ensure that data flows identified by static analysis can be triggered by dynamic analysis? Often, data flows identified statically are difficult to trigger dynamically due to the absence of user inputs or behaviors. Could enhancing code coverage be a viable solution for improvement?
-
2/ Double Clobbering in Dynamic Analysis: How does TheThing handle scenarios where two payloads are injected simultaneously during dynamic analysis?
-
3/ Double Clobbering with Exception Handling: Does TheThing take into account scenarios involving exception handling, such as when variable definitions are within a try block and the catch block uses these variables for sensitive operations? This scenario should be considered a typical case of double clobbering.
- Related Works
- HTML Injection
- DOM Clobbering
- Evaluation
- Discussion
- Others