mcpField
C
create-pass-through-approximation

create-pass-through-approximation

github.com/seqra安全17059 次安装1 天前更新
代码仓库

关于 create-pass-through-approximation

面向 OpenTaint 的安全技能，根据源码描述不透明方法中的数据传播，并写入对应配置与构建记录，适用于方法级污点分析。

主要功能

  1. 01追踪接收者和参数的数据流
  2. 02描述返回值、参数及接收者流向
  3. 03用虚拟字段表示对象存储
  4. 04按包编写 passThrough 配置
  5. 05更新 build.done 记录

适用场景

  1. 01恢复不透明调用中丢失的污点流
  2. 02建模通过存储数据的 setter 和 getter
  3. 03添加或修复指定方法的近似规则

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/seqra/opentaint --skill create-pass-through-approximation

安装后在 Claude Code 中输入/create-pass-through-approximation确认已加载。

附带文件references/java.md

详细介绍

技能：创建 PassThrough 近似配置

将被丢弃方法的污点传播建模为 PassThrough 近似配置——这是一种配置，用于告知引擎数据如何从方法的输入流向输出，从而恢复分析器因不透明调用而丢失的数据流。

输入

由调用方提供；未提供时使用默认值。仅当缺少必需输入且没有合理默认值时才询问

  • project-root（可选）——目标项目的根目录。Opentaint 会将所有分析产物保存在固定的 <project-root>/.opentaint/ 目录下，因此下方的每个 .opentaint/... 路径都会解析到该目录。默认值：当前目录
  • language（必需）——此项目的目标语言及特定于该语言的说明
  • batch（必需）——批次 ID；其 passthrough 条目位于 .opentaint/tracking/approximations/<batch>.yaml，并将你构建的条目追加到该文件的 build.done
  • methods（可选）——指定的 { method, signature } 子集；当调用方只需要处理这些方法时，用它们替代整个 passthrough 分组

工作流

1. 了解传播方式

对于批次中尚未列入 build.done 的 passthrough 方法（或指定给你的 methods），请依据语言参考，阅读每个方法的实际源码并进行分析。只根据方法自身的代码建模，不考虑项目如何使用该方法——配置描述的是方法固有的传播方式。回答：输入数据去了哪里？到达接收者或参数的数据，是否会通过返回值、方法写入的参数、接收者，或其存入的对象或字段传出？还要注意对象是否会在多次调用之间保留数据（例如，setter 暂存数据，getter 之后将其取出；或构建器不断累积数据）——这种情况需要虚拟字段。这种传播形态就是配置要表达的内容。

2. 编写配置

在 .opentaint/pass-through 下，每个包编写一份 passThrough 配置（格式和模式见语言参考）。已列入 build.done 且未在 methods 中明确指定的方法已构建并可信——保持其本身及其配置不变。在现有配置中修复明确指定的方法；向对应包的现有配置添加新方法，而非重写整个文件。复制规则由两个要点决定：

  • 覆盖每个位置——this 和每个参数：将每个位置复制到数据流向的位置；如果数据没有流向别处，则复制到其自身
  • 当数据在多次调用之间保存在对象中时，让写入方和读取方通过同一个虚拟字段传递数据——这是一个两者命名完全相同的名义存储位置。写入方暂存的数据就是读取方取回的数据；如果两者命名不同，污点就会丢失。
3. 重新检查配置

返回前，确认每个需要建模的方法都有 passThrough 配置，并且每份配置中的复制规则确实符合方法源码中的数据流向——覆盖每个位置，且写入方和读取方使用完全相同的虚拟字段。按照 Tracking，将每个尚未列入 build.done 的已编写方法追加进去；修复的方法仍保留在其中。

输出

简短、精炼地报告完成的工作

产物：
  • .opentaint/pass-through/<package-kebab>.yaml——passThrough 配置文件；每个包一份（一个依赖可以跨多个包），文件以包名命名（完整文件格式见语言参考）
  • 批次文件 build.done 中已成功构建的方法（追加新方法；修复的方法已记录在其中，遵循 Tracking）
摘要：
  • 写入的配置路径及已建模的方法

跟踪

.opentaint/tracking/approximations/<batch>.yaml — 一个批次的可调用项分类，<batch> 为计划文件名的主体。每个可调用项恰好属于一个判定类别，并使用计划中的精确语言专属 method 和 signature 作为键，以便区分不同变体：

  • passthrough、dataflow — 已建模的传递项；每个条目为 { method, signature }
  • skipped — 终止性非传递项；每个条目为 { method, signature, reason }
  • engine_issues — 单独的类别，用于引擎已证实无法传播的传递项（已构建但仍被丢弃）；每个条目为 { method, signature, reason }。它们是终止性的，处理方式与 skipped 完全相同——唯一区别在于原因。merge-skipped 会将其作为独立的 engine_issues 组并入 skipped.yaml，与常规的 methods 跳过项并列。

dependencies 列出数据流测试项目所需的依赖标识符。build 块用于跟踪构建情况——test_project 记录每个数据流方法的测试项目状态（如果已将样例写入该批次的测试项目，则为 done；如果无法写入样例、因此该方法未纳入其中，则为 failed），而 done 存放已完成的 { method, signature }。通过注释明确说明

passthrough:
  - { method: "<qualified-member-a>", signature: "<language-signature-a>" }
dataflow:
  - { method: "<qualified-member-b>", signature: "<language-signature-b>" }
skipped:
  - { method: "<qualified-member-c>", signature: "<language-signature-c>", reason: "retains none of its input data" }
engine_issues: []
dependencies: []
build:
  test_project:
    - { method: "<qualified-member-b>", signature: "<language-signature-b>", status: done }
  done: []

此技能只会在方法成功构建后，且 build.done 中尚无该方法时，将其追加为 { method, signature }。新分配的方法若未能写入，就不会被记录，因此循环会返回处理它；明确修复的方法则保留其现有条目不变。绝不触碰分类类别，也不编辑 build.done 中已有的条目。

约束

OpenTaint 是一种全程序、过程间、字段敏感的别名分析引擎。它已经能通过可见的应用代码、调用、别名和独立字段传播；自定义规则和近似仅用于建模指定的源、汇或不透明方法边界。编译时常量和字面量不携带污点，因此，输出仅为常量的源或传递项不会引入任何内容。

  • 每条规则只建模一个函数——绝不要使用正则表达式／通配符匹配器，也不要使用覆盖多个参数的位置；过度建模会让污点通过未经审核的方法传播，并制造误报
  • 生成的配置中不要包含注释

评论

支持 Markdown