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

在 JavaScript 安全分析中，CodeQL 是一个强大的静态分析工具，能够帮助开发者发现潜在的安全问题。然而，在实际应用中，我们经常会遇到一些调用节点（CallNode）无法解析到具体实现的情况，这可能导致数据流分析中断，从而影响问题检测的准确性。

未解析调用节点的问题

在 JavaScript 项目中，当 CodeQL 无法解析某个函数调用的具体实现时，会产生所谓的"未解析调用节点"。这些节点通常出现在以下几种情况：

1. 调用的函数来自未分析的依赖项
2. 动态调用（如通过回调函数或数组索引调用）
3. 使用了某些特殊的内置方法

这些未解析的调用节点可能会中断数据流分析，导致安全问题被漏报。但并非所有未解析的调用都会真正中断数据流，因为 CodeQL 对一些常用方法（如 path.join()）有专门的流传播规则。

识别真正中断数据流的调用节点

为了准确识别那些真正会中断数据流的未解析调用节点，我们可以采用以下方法：

1. 排除已知有传播规则的调用

CodeQL 对一些常用方法有内置的流传播规则。我们可以通过 SummarizedCallable 类来识别这些有特殊处理的调用：

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

2. 结合安全查询配置

不同的安全查询可能有不同的流传播规则。我们可以通过检查各个安全配置的 isAdditionalFlowStep 谓词来进一步过滤：

predicate isSink(DataFlow::Node sink) {
  sink instanceof InterestingUnresolvedCallWithSummary and
  not CIQ::CodeInjectionConfig::isAdditionalFlowStep(_, sink) and
  not TPQ::TaintedPathConfig::isAdditionalFlowStep(_, _, sink, _)
}

3. 参数流步骤处理

对于未解析的调用节点，我们需要特别处理其参数流：

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*()
  }
}

实际应用建议

在实际项目中应用这些技术时，建议：

1. 首先识别所有未解析的调用节点
2. 过滤掉那些有特殊传播规则的调用
3. 针对剩余节点分析它们是否真正中断了数据流
4. 根据需要添加自定义的流传播规则

这种方法可以帮助开发者更精确地定位那些真正影响安全分析结果的调用节点，从而提高问题检测的准确性。

通过系统地识别和处理这些中断数据流的调用节点，我们可以显著提升 CodeQL 在 JavaScript 项目中的安全分析能力，发现更多潜在的安全隐患。