CodeQL JavaScript项目中识别中断数据流的未解析调用节点

在CodeQL JavaScript静态分析项目中，开发人员经常需要识别那些导致数据流中断的未解析函数调用节点。这类问题通常出现在分析npm包问题时，特别是当调用图(call graph)中存在无法解析被调用方(callee)的情况。

问题背景

JavaScript的动态特性使得静态分析工具在解析某些函数调用时会遇到困难。CodeQL通过数据流分析追踪变量和值的传播路径，但当遇到无法解析被调用方的函数调用节点(CallNode)时，数据流可能会中断，导致潜在的安全问题被遗漏。

识别未解析调用节点

CodeQL提供了直接查询未解析调用节点的方法：

class UnresolvedCallNode extends DataFlow::CallNode {
  UnresolvedCallNode() {
    not exists(this.getACallee(0))
  }
}

这个类会匹配所有没有解析到被调用方的函数调用节点。但直接使用这个类会包含太多误报，因为CodeQL内置了许多流行API的传播规则，即使没有解析到具体实现，数据流仍能继续。

过滤无关调用节点

我们需要进一步过滤掉那些虽然未解析但CodeQL已经内置了传播规则的调用节点：

class InterestingUnresolvedCallNode extends UnresolvedCallNode {
  InterestingUnresolvedCallNode() {
    not(
      this.getCalleeName() = "require" or
      this.(DataFlow::CallNode).getReceiver().(DataFlow::ExprNode).asExpr().(VarAccess).getVariable().getName() = "console"
    )
  }
}

这个过滤条件排除了require()和console相关调用，因为它们通常不会中断数据流。

处理CodeQL内置的传播规则

CodeQL通过两种方式处理未解析调用的数据流传播：

1. SummarizedCallable：CodeQL内置的通用函数摘要模型
2. 特定安全配置的附加流步骤：如TaintedPathConfig和CodeInjectionConfig中的isAdditionalFlowStep

我们可以通过检查调用节点是否被这些机制覆盖来进一步过滤：

class InterestingUnresolvedCallWithSummary extends InterestingUnresolvedCallNode {
  InterestingUnresolvedCallWithSummary() {
    any(SummarizedCallable summary).getACallSimple() = this
    or
    TPQ::TaintedPathConfig::isAdditionalFlowStep(_, _, this, _)
    or
    CIQ::CodeInjectionConfig::isAdditionalFlowStep(_, this)
  }
}

实际应用：安全问题分析

在实际安全分析中，我们可以将这种技术应用于特定类型的问题检测。例如，在代码注入问题分析中：

module CodeInjectionConfigNew implements DataFlow::ConfigSig {
    predicate isSource = CodeInjectionConfig::isSource/1;
    predicate isSink(DataFlow::Node sink) {
     sink instanceof InterestingUnresolvedCallWithSummary and
     not CodeInjectionConfig::isAdditionalFlowStep(_, sink)
  }
}

这种配置可以帮助我们识别那些真正中断数据流、可能导致问题被遗漏的调用节点。

技术挑战与解决方案

1. 动态回调函数：JavaScript中常见的回调模式会导致大量调用节点无法解析。解决方案是添加参数流步骤规则：

class ParamStep extends TaintTracking::SharedTaintStep {
  override predicate step(DataFlow::Node nodeFrom, DataFlow::Node nodeTo) {
      nodeTo instanceof DataFlow::InvokeNode
      and not exists(nodeTo.(DataFlow::InvokeNode).getACallee(0))
      and nodeFrom = nodeTo.(DataFlow::InvokeNode).getAnArgument*()
  }
}

2. 跨配置传播规则：某些调用在一个安全配置中没有传播规则，但在另一个配置中有。需要检查多个配置的isAdditionalFlowStep。

最佳实践

1. 优先使用SummarizedCallable过滤已知传播规则的调用
2. 对于特定类型的安全分析，检查相关配置的附加流步骤
3. 考虑JavaScript常见模式(如回调、动态属性访问)对数据流分析的影响
4. 结合多种技术(如参数流步骤)提高分析的完整性

通过这种方法，开发者可以更精确地识别那些真正影响分析结果的未解析调用节点，从而有针对性地改进分析规则或代码实现。