## 分析原则

- 分析过程全覆盖，包含完整数据流
- 关键代码**逐行分析**，充分理解代码语义
- 防护手段可用性评估，**基于实际代码角度**分析，防护手段有效时要充分论证，敢于下判断

## 任务步骤

### Step2.1 根据缺陷和语言加载对应分析规则

#### 漏洞规则

- SSRF: `taint-analyze/vulnerabilitys/SSRF.md`
- SQL_INJECTION: `taint-analyze/vulnerabilitys/SQL_INJECTION.md`
- PATH_TRAVERSAL: `taint-analyze/vulnerabilitys/PATH_TRAVERSAL.md`
- BUFFER_OVERFLOW: `taint-analyze/vulnerabilitys/BUFFER_OVERFLOW.md`
- DESERIALIZATION: `taint-analyze/vulnerabilitys/DESERIALIZATION.md`
- COMMAND_INJECTION: `taint-analyze/vulnerabilitys/COMMAND_INJECTION.md`

对于未列出的漏洞类型，你需要自行列举分析的关键点

#### 语言规则

如果代码文件匹配下面的语言，需要加载语言规则

- JAVA: `taint-analyze/languages/java.md`

### Step2.2 检查缺陷点真实性

根据缺陷点描述，分析缺陷点函数是否确实包含相关的代码逻辑，如命令注入需要有执行命令的底层函数

如果通过分析发现缺陷点函数底层不存在对应的代码操作，则该缺陷为误报，结束所有流程，输出分析结果

### Step2.3 数据流分析

#### 分析方式

根据代码实现，分析代码调用的完整数据流，包括定义（调用代码的实现）和引用（该代码块被哪块代码调用），识别校验防护，最后得出安全漏洞结论。

#### 特别声明

请严格遵循以下声明完成报告输出，否则你会被扣除所有评分，这会导致你的回答作废
1.一个完整的数据流应当是从用户可控的输入开始的，也就是说，引用要分析到用户可控的输入或确认用户不可控才终止，如：要确认到http接口路由定义和实现才知道数据来源为网络请求。
2.数据流分析要逐步分析，首先应该分析 缺陷所在函数 的完整实现，然后再根据实际代码实现逐级分析数据流。如果分析完对应函数即是完整数据流，则应直接给出结论。
3.数据流应当包含从用户可控的外部输入到利用点的完整链路，不要假设、虚构、猜测，严格按照代码内容进行分析。
4.要注意代码中是否存在安全防护/校验函数，如果存在则必须要获取相关代码进行分析，确认漏洞是否可以利用再给出结论。
5.如果已经确认对应污点参数存在安全防护/校验函数且无法绕过，则应当直接给出安全漏洞不存在的结论，不要继续分析，输出结论即可。
6.用户可控输入主要有以下来源，均视为用户可控：
- 网络请求：如http/私有协议/rpc/域套接字
- 跨进程通信：如ipc(共享内存/消息队列/信号量)管道/信号
- 文件读取：如配置文件读取，日志文件读取等
- 中间件读取：如从另外一个服务读出的，如数据库、消息中间件（kafka）、缓存中间件（redis）等
- 命令行参数
- 环境变量
- 其他可控输入
7.<数据流>的mermaid图的起始点必须是用户可控输入相关的信息/函数
- 对于HTTP请求，起始点应当是请求的接口URI
- 对于文件读取，起始点应该是文件路径/路径对应的变量
- 对于环境变量，起始点应该是环境变量名
- 对于命令行参数，起点应该是参数名
- 对于中间件类型，起点应该是设置中间件字段内容的代码逻辑的数据来源
- 对于确认已有安全防护/校验函数，无法触发漏洞，起始点可以是其对应的防护函数
8.<关键代码片段>需要列举出<数据流>描述的所有函数对应的关键代码，代码和<数据流>中描述的步骤应当一一对应
9.你应当主要关注代码仓库自身的代码逻辑，如果数据流分析过程中涉及第三方通用库或框架，则应当根据其对应特性直接分析，无需进一步查找第三方相关实现
10.如果针对某个函数和变量，通过多次（4次以上）查找都没有找到，说明可能不在代码仓库中，直接按照代码上下文的逻辑做判定即可，无需继续查找分析

### Step2.4 分析回顾检查项

- 防护校验手段是否识别？
  - 存在性识别，防护代码列举
  - 有效性识别，防护逻辑**逐行推断**
  - 覆盖范围确认，防护逻辑**是否覆盖风险数据流**
- 数据流是否完整？
  - Source 到 Sink 的链路完整吗？
  - Source点是否真实？
  - Sink点是否真实？
- 幻觉检查
  - 是否存在未经验证的假设性结论？

## 补充说明

### 不存在安全漏洞特定场景

分析过程中如果符合任一下述场景，应当直接结束分析并给出不存在安全漏洞的结论
1.如果分析过程中已确认 用户可控输入 为代码中定义的常量或非外部可控的变量，则结论应当为不存在安全漏洞。
2.如果分析过程中已确认 用户可控输入 类型为整形、布尔型或枚举型等无法有效拼接的类型，则结论应当为不存在安全漏洞。
3.如果分析的数据流中某个代码片段代码是注释掉的，数据流不完整，则无需继续分析，结论应当为不存在安全漏洞。
4.如果污点参数存在默认值判断，在校验失败后，被赋值为硬编码常量，如 if (!"asc".equals(key)) { key = "desc"; ……}，参数仅能为"asc"/"desc"，结论应当为不存在安全漏洞。
5.如果污点参数在传递时，经过if，case等逻辑判断，当参数设为漏洞利用参数时无法通过判断的，结论应当为不存在安全漏洞。


