go SqlInjection ... Ellipsis

[yhy0]

I am a novice, when ... If the data flow is interrupted, how should I add additional steps?

Injection not detected。

If that's all right.

How should I add an extra step to connect the data stream

[smowton]

I'm afraid this is a currently-known shortcoming of the Go analysis -- we're working on this at the moment, but for now varargs functions called using a list of implicit array arguments (i.e., not using ...arr syntax to pass an array explicitly) don't work as expected.

In simple cases using TaintTracking::Configuration it may suffices to add code like

private predicate isVarargsParam(Parameter p) {
  exists(ParameterDecl pd, FuncTypeExpr tp | pd = tp.getAParameterDecl() |
    p.getDeclaration() = pd.getANameExpr() and
    pd.getTypeExpr() instanceof Ellipsis
  )
}

class TaintConfig extends TaintTracking::Configuration {
  TaintConfig() { this = "taint-configuration" }

  override predicate isAdditionalTaintStep(DataFlow::Node source, DataFlow::Node sink) {
    exists(Parameter p, DataFlow::ArgumentNode an, int idx |
      an = source and
      p = an.getCall().getACallee().getAParameter() and
      isVarargsParam(p) and
      not an.getCall().hasEllipsis() and
      an.argumentOf(_, idx) and
      idx >= p.getIndex() and
      sink.asParameter() = p
    )
  }
}

This will do what you want so long as query itself is tainted on calling TT -- it won't work if just the Sort field of TT is tainted, because additional steps only apply to "top level" taint.

To use this with a DataFlow::Configuration instead of a TaintTracking::Configuration we'd need to target not the varargs parameter itself, but an array-read from it, like sink.(Read).readsElement(p.getARead(), _). This would also only work if query is the value we're tracking, not a value stored in one of its members.

Both of these solutions use a cross-function additional step, called a "jump step", which results in loss of call-stack context. This could result in impossible caller/callee pairings, like taint entering from caller1 -> callee then returning callee -> caller2, which CodeQL dataflow usually works hard to exclude.

So these workarounds are not great, but perhaps they will help with your case -- otherwise please bear with us while we implement a higher quality solution!

[owen-mc]

Taint flow should now be correctly tracked through varargs parameters, since this PR was merged. So your original problem should be fixed, and you shouldn't need the workaround that @smowton suggested.