php-sql-audit

PHP SQL injection audit (php-sql-audit)

Analyze PHP project source code, identify SQL execution-related code (PDO/mysqli/ORM), trace user input to SQL construction points, verify whether SQL injection exists, and output a complete vulnerability report.

CRITICAL: omission prohibited and false positives prohibited

Must audit all paths where string sources appearing in route parameters (GET/POST/Body/parameter fields) enter SQL
Must use "data flow tracing evidence" to determine exploitability; must not rely only on keyword guessing
Omission prohibited: no omission placeholders may appear; must output a complete vulnerability evidence chain and remediation recommendations

Grading and numbering

See:shared/SEVERITY_RATING.md
Vulnerability number:{C/H/M/L}-SQL-{序号}

Input dependencies

It is recommended to have at least (consistent with shared/IO_PATH_CONVENTION.md ; when merging pipelines, just read the equivalent section in the overall report):

routes_{timestamp}.md(when stored independently, often route_mapping/routes_{timestamp}.md）
params_{timestamp}.md(when stored independently, often route_mapping/params_{timestamp}.md) Optional but recommended:
route_tracer/ output, used to precisely determine the actual usage status of parameters

SQL Sink identification (required)

PDO / PDOStatement
- Relatively dangerous:$pdo->query($sql) / $pdo->exec($sql)(if $sql comes from concatenation/includes user input)
- Form check:$pdo->prepare($sql) only when $sql placeholders are used in and subsequently bindParam/bindValue or parameters are passed correctly is it safer
- ORM/DB wrappers:DB::select(DB::raw({value}))、Doctrine createQuery , etc.
mysqli / mysqli_stmt
- mysqli_query($conn, $sql) concatenation dangerous
- mysqli_prepare only possibly safe when prepare + bind are correct
Typical dangerous construction patterns (required)
- SQL string concatenated with variables:., sprintf, vsprintf, implode/join + SQL keywords
- Dynamic sorting:order by $x / ORDER BY ".$x."(commonly high risk)

Conditions requiring tracer invocation (required)

When any one is satisfied, must call php-route-tracer(or equivalent tracing evidence):

Parameters pass through multiple layers of transmission or fields are extracted after JSON decoding and enter SQL
The SQL construction point is located in a base class/utility class/parent function
Branch conditions (if/try/catch) exist, causing uncertainty about whether the SQL executes

Report output

Output to:

{output_path}/vuln_audit/
└── sql_{timestamp}.md

Vulnerability report entry template (mandatory)

### [{等级前缀}-SQL-{序号}] {风险标题}

| 项目 | 信息 |
|------|------|
| 严重等级 | {🔴/🟠/🟡/🔵} (CVSS {score}) |
| 可达性 (R) | {0-3} - {理由} |
| 影响范围 (I) | {0-3} - {理由} |
| 利用复杂度 (C) | {0-3} - {理由} |
| 可利用性 | ✅ 已确认 / ⚠️ 待验证 / ❌ 不可利用 / 🔍 环境依赖 |
| 位置 | {file}:{line} ({Function/Class}) |

#### 数据流链（Source → Sink）
（按路由逐行写出：请求参数读取 -> 变量赋值/拼接/转换 -> 分支 -> SQL 进入执行点。禁止省略）

#### 可利用前置条件
- 鉴权要求：{无需/需登录/需特定权限}
- 输入可控性：{完全可控/条件可控/不可控}
- 触发条件：{分支/异常/环境依赖}

#### 证据引用（强制：来自 php-route-tracer）
每条 SQL 疑似漏洞必须逐项引用 trace 输出中 `## 9) Sink Evidence Type Checklist` 的 **SQL 行**对应证据要点（允许状态为待验证，但证据引用必须存在）：
1. `EVID_SQL_EXEC_POINT`：SQL 执行函数/语句位置（对应 trace 的 SQL 执行点证据）
2. `EVID_SQL_STRING_CONSTRUCTION`：SQL 字符串构造/拼接位置（对应 trace 的 SQL 拼接证据）
3. `EVID_SQL_USER_PARAM_TO_SQL_FRAGMENT`：用户可控参数到 SQL 片段的映射（对应 trace 的可控性矩阵字段证据）

#### tracer 证据缺失处理（强制）
- 若无法定位上述 1~3 任一关键证据要点：该漏洞状态只能标记为 `⚠️待验证`，不得直接给出 `✅已确认可利用`。

#### 验证 PoC（强制，可执行请求）
```http
{HTTP Method} {完整路径与查询/Body} HTTP/1.1
Host: {host}
{必要 Header/Session/JWT/Cookie}

{Payload}

Recommended fix

Provide key points for secure coding (PDO prepare + bind and ensure SQL fragments do not concatenate user input)
Provide code search statements (rg/grep style) for locating all similar concatenation points


## 输出完整性检查（强制）
- [ ] 至少输出：风险统计 + 每条漏洞完整条目
- [ ] 不出现任何省略占位符
- [ ] 每条漏洞都包含：数据流链、可利用前置条件、可执行 PoC、修复建议