在 OWASP Top 10:2025 里，Injection 排在 A05，也就是第 5 位。它从 2021 年的第 3 位下降到了第 5 位，但依然是最经典、最常见、也最容易造成高危后果的一类漏洞。它的核心很简单：不可信输入进入了解释器，并被当成命令、语句或结构的一部分执行了。
来源：OWASP Top 10:2025 Introduction
来源：A05:2025 Injection

你可以把它理解成：
程序原本只是想“处理数据”，但因为数据和命令没有分开，结果攻击者把数据伪装成命令，解释器就替他执行了。

为什么它仍然危险
OWASP 官方页面提到，这一类风险依旧是 100% 被测试应用都会关注的类别之一，覆盖 37 个 CWE，而且相关 CVE 数量是所有类别里最多的一批。它里面既包括频率高但单次影响未必最大的 XSS，也包括频率可能没那么高但破坏力极强的 SQL 注入、命令注入。

常见表现

• SQL 注入、NoSQL 注入
• OS 命令注入
• LDAP 注入
• ORM/HQL 注入
• EL / OGNL 注入
• XML / XPath / CRLF / 代码注入
• 服务端模板注入、本地或远程包含等同类问题

典型根因

• 用户输入没有做服务端校验、过滤、清洗。
• 动态查询或命令直接拼接字符串。
• ORM 只是换了语法，但本质还是拼接查询。
• 需要“结构”的地方也允许用户输入结构，比如表名、列名、排序字段。
• 只做通用转义，不做“按上下文”的转义和分离。

OWASP 官方典型场景

• 把 id 参数直接拼进 SQL，攻击者传入 ' OR '1'='1，查询条件被篡改，直接返回全部数据。
• 用 HQL/ORM 以为更安全，但仍然拼接用户输入，结果依旧能绕过过滤条件读出所有账户。
• 把用户输入直接传进 Runtime.exec() 或类似调用，攻击者在域名参数后拼接额外命令，直接在服务器上执行系统命令。

怎么防

• 最核心原则是：让数据和命令分离。
• 优先使用安全 API、参数化查询、预编译接口，或能避免直接调用解释器的高级抽象。
• 做正向的服务端输入校验，而不是只做前端过滤。
• 对残余的动态结构，使用解释器特定的上下文转义，但要知道这只是补救，不是最强防线。
• 不要让用户决定表名、列名、排序表达式等结构性内容。
• 把 SAST、DAST、IAST、Fuzzing 等检测能力加入 CI/CD。
• 测试时不要只测表单参数，也要覆盖 Header、Cookie、URL、JSON、SOAP、XML 等所有输入面。

补充理解
OWASP 页面还专门提到：LLM 里的 Prompt Injection 已经成为相近的一类新问题，但它被单独放在 OWASP LLM Top 10 里，而不是并入传统 Web Injection。

一句话总结
Injection 的本质是：系统没有把“用户数据”和“解释器要执行的命令/语句”严格分开。