[javascript] TaintTracking of html with external scripts

[codeqln00b]

I want to analyze single html page with all external scripts for DOM based XSS. I made a simple page https://github.com/codeqln00b/xss/blob/master/index.html where both default lgtm queries https://lgtm.com/projects/g/codeqln00b/xss/?mode=list and my TaintTracking::Configuration
https://lgtm.com/query/5557762570152634122/
unable to find vulnerable usage of b variable. What I am doing wrong? Is it possible to do it with codeql?

[adityasharad]

Looking at https://lgtm.com/projects/g/codeqln00b/xss/alerts/?mode=list and the results of your custom query, I see that the two XSS vulnerabilities you introduced are correctly flagged by CodeQL.

• index.html has one: GitHub link, LGTM.com link
• main.js has one: GitHub link, LGTM.com link

In both your example files, there is no vulnerability involving the variable b, and so I think it is reasonable that CodeQL does not flag it:

• In index.html you have document.write(b) here but the variable b is undefined.
• In main.js you define the variable b here but it is never passed to document.write.

Perhaps you meant to update your examples so that b was also used in an XSS vulnerability?

[codeqln00b]

index.html includes main.js, so b should be defined here
If I set window.name to <script>alert(1)</script> or to any other payload and open index.html in web browser, payload inserts 3 times

[asgerf]

Hi 👋. I can confirm that we don't track data flow from global variables in main.js to global variables index.html.

We'll look into improving this, but in the meantime you can add this extra step to your taint-tracking configuration to enable full flow through globals: (here is the query with that step added)

  override predicate isAdditionalTaintStep(DataFlow::Node pred, DataFlow::Node succ) {
    exists(GlobalVariable var |
      pred = var.getAnAssignedExpr().flow() and
      succ = var.getAnAccess().flow()
    )
  }

I understand you might be wondering why we don't include this step by default. A lot of our work is driven by variant-analysis of real-world vulnerabilities, and this type of data flow is quite rare outside of synthetic tests like yours. I'd be very interested to hear about any real-world vulnerability where this step was needed.

What you'd typically find is that the <script src=...> tag is generated by a build script, and the data actually goes through an import statement, and possibly through a function call, rather than being passed around in a global variable.