Not a bug; just a suggestion, as we've had similar ideas to detect DOM XSSes.
Since TTT is a Chrome extension, and is a tool for pentesters/bughunters, you might use Trusted Types default policy instead of hijacking all the sinks in JavaScript. Essentially, something along those lines:
if (window.TrustedTypes && !TrustedTypes.getPolicyNames().includes('default')) {
TrustedTypes.createPolicy('default', {
createHTML: (s) {
if (isTainted(s)) {
throw; // The callstack can give you the sink.
}
return s; // not tainted, just let the app use the sink.
},
// same for other createXYZ.
});
} else {
// existing sink hooking logic
}
There's a few caveats (the API shape might change, it will work for now only if "Experimental web platform features" flag is enabled, we don't support XHR as a sink etc.), but this might be more elegant way to cover the DOM XSS sinks for your use case. See also https://github.com/WICG/trusted-types/issues/131 as the default policy will soon have more context when invoked.
cc @engelsdamien who had a very similar idea and a rudimentary proof of concept.
Not a bug; just a suggestion, as we've had similar ideas to detect DOM XSSes.
Since TTT is a Chrome extension, and is a tool for pentesters/bughunters, you might use Trusted Types default policy instead of hijacking all the sinks in JavaScript. Essentially, something along those lines:
There's a few caveats (the API shape might change, it will work for now only if "Experimental web platform features" flag is enabled, we don't support XHR as a sink etc.), but this might be more elegant way to cover the DOM XSS sinks for your use case. See also https://github.com/WICG/trusted-types/issues/131 as the default policy will soon have more context when invoked.
cc @engelsdamien who had a very similar idea and a rudimentary proof of concept.