# 缺陷点分析任务

## 前置条件

- 待审计代码文件（行号范围）

## 分析步骤

! 严格按照下述步骤进行分析，不允许跳出流程或者裁剪步骤
! 按照状态机串行推理，不允许直接分析得出结果
! 遵循最佳实践分析

### Step1 加载分析规则

根据代码语言加载风险分析规则（必须）：

  - java: `<本SKILL根目录>/threat-explore/limits/java.md`
  - python: `<本SKILL根目录>/threat-explore/limits/python.md`
  - go: `<本SKILL根目录>/threat-explore/limits/go.md`
  - cpp: `<本SKILL根目录>/threat-explore/limits/cpp.md`
  - 其他：`<本SKILL根目录>/threat-explore/limits/default.md`

### Step2 初步分析该代码涉及什么类型的敏感操作

步骤产物：**敏感操作列表**
产物示例：
- xx行，engine.executexxx 代码存在缓冲区溢出

#### Sink类敏感操作

- SQL 注入：数据库执行函数或者ORM操作函数（如 cursor.execute、Session.execute、engine.execute、mapper.queryXXX）。
- 命令注入：系统调用函数（如 Python 的 os.system、subprocess.Popen，Java 的 Runtime.exec，Go 的 exec.Command）。
- 路径穿越：文件操作函数（如 open、os.open、os.path.join、java.io.FileInputStream、fs.readFile）。
- SSRF：服务端 HTTP 请求函数（如 Python 的 requests.get、urllib.request.urlopen，Java 的 HttpClient.send，Go 的 http.Get，Node.js 的 axios.get）。
- 反序列化：反序列化函数或者存在CVE的部分反序列化库函数（如 Python 的 pickle.loads、yaml.load，Java 的 ObjectInputStream.readObject、XMLDecoder.readObject、fastjson.parseObject、fastjson.parse，PHP 的 unserialize）。
- 代码注入：代码执行函数（如 Python 的 eval、exec，Java 的 ScriptEngine.eval、GroovyShell.evaluate，PHP 的 eval、create_function）。
- JNDI注入：触发JNDI查找的函数（如 InitialContext.lookup、 InitialDirContext.search、 JndiTemplate.lookup等显式触发jdni查找的，还有如 JdbcRowSetImpl.connect、 JndiObjectFactoryBean.afterPropertiesSet等内部隐含jdni查找行为的）。
- 不安全反射：通过反射构造类或执行代码的函数（如 Class.newInstance、 Proxy.newProxyInstance、 Constructor.newInstance、 URLClassLoader.newInstance、 Method.invoke等)。
- 表达式注入：可执行表达式的函数（如 jakarta.el.ELProcessor.eval、ValueExpression.getValue 等，以及 JUEL、Tomcat 等 EL 实现中封装的执行 EL 表达式的函数）。
    - SpEL表达式：可执行SpEL表达式的函数（如 org.springframework.expression.Expression.getValue和其他spring系列框架封装的执行SpEL表达式的函数）。
    - ONGL表达式：可执行OGNL表达式的函数（如 TextParseUtil.translateVariables、 OgnlTextParser.evaluate、 Ognl.getValue等）。
- 模板注入： 模板渲染函数（如 org.thymeleaf.TemplateEngine.process、freemarker.template.Template.process、org.apache.velocity.Template.evaluate 等）。
- LDAP注入：可进行LDAP查询的函数（如 InitialLdapContext.search、InitialDirContext.search等）。
- 硬编码凭证：字面量作为敏感凭据的赋值代码、某函数调用安全校验相关函数使用字面量作为密钥/密码 等
- 格式化字符串漏洞：格式化输出函数（如 C/C++ 的 printf、sprintf、fprintf、snprintf，Python 的 % 格式化操作）。
- 缓冲区溢出：缓冲区溢出漏洞不要求必须调用特定标准库函数。只要代码中存在可能导致内存越界写入的语义行为，即应视为漏洞。如果存在内存操作函数（如 C/C++ 的 memcpy、strcpy、sprintf、wcscpy、wcscat、gets、strcat 等），则一定要视为缓冲区溢出漏洞。
- NoSQL注入：执行NoSQL查询的函数
- CSV注入：解析CSV内容的函数
- XXE注入：解析XML内容的函数

### Step3 分析敏感操作能否被触发

逐个分析Step2中列举的敏感操作列表

! 如果某个敏感操作无法触发或者没有风险，则无需检出
! **分析范围仅限于待审计文件路径**，更大范围的上下文分析由其他任务完成，本任务不涉及
! 因为超出审计范围导致不确定风险的敏感操作，应当视为有风险，再由后续任务分析

#### 外部输入列举

包括但不限于:

- 函数参数
- 请求体
- 环境变量
- 文件内容
- URL Query
- Header
- 表单
- 中间件（数据库、消息队列、缓存等存在二次注入可能）
- ...

#### 分析输出规则

* 只识别 **预定义漏洞类型**，其他一律不报。
* 必须 **调用漏洞触发点** 才可报；否则即使校验不足也 **不报**。
* 若仅有 **可能风险/校验不足/未过滤** ，但 **没有触发点的实际调用** ，不报。
* 若 **外部输入** 是常量，不报。
* 存在 **外部输入** 影响关键参数，才认定为风险敏感操作
* 不得将整个函数体或仅函数定义行/函数签名行作为行号范围。

### Step4 组织敏感操作风险列表

列出具有风险的敏感操作列表

### Step5 回顾检查与总结

回顾Step2列出的**敏感操作列表**，总结风险情况，完成下面的检查：

- 检查项1：是否有遗漏的敏感操作风险未输出或未分析

### Step6 输出最终报告

根据Step5的检查结果，按外部输入变量和函数组织报告结果输出

按下面的格式输出识别到的敏感操作信息：

```markdown
## Sink类敏感操作

### 风险操作1：xxx
- 函数签名
- 外部输入
- 代码文件路径
- 关键操作代码片段（带行号范围）
- 敏感操作描述+潜在危害

```

## 最佳实践

- 搜索代码
  - 错误做法: Grep搜索到敏感操作代码行后直接根据搜索到的内容进行分析
  - 最佳实践: Grep到所在行后，读取所在行代码上下文，理清功能逻辑
- 检出结果
  - 错误做法: 输出所有敏感操作
  - 最佳实践1: 先进行可触发性分析，只检出可触发的漏洞
  - 最佳实践2: 输出敏感操作时，同一个函数内的外部输入源相同的漏洞合并检出
- 代码分析
  - 错误做法: 进行跨文件的污点追踪上下文分析
  - 最佳实践: 简单梳理风险上下文，如果存在风险或者有未确定的风险则检出，由后续任务进行复杂分析


