SQL注入至今仍是Web安全领域最危险的漏洞之一，即便使用ORM框架也不能完全高枕无忧。很多人以为用了Hibernate、MyBatis、Entity Framework或者SQLAlchemy就自动免疫注入了，实际上ORM只是把拼接过程封装了一层，一旦使用不当，照样能把数据库暴露给攻击者。真正的问题不在于用不用ORM，而在于开发者是否清楚ORM在哪些场景下会退化成字符串拼接，以及如何用规范化的方式堵住这些口子。
ORM不是防火墙，参数绑定才是底线
所有主流ORM框架的核心防注入机制都是参数化查询，也就是把SQL结构和数据值分离，由数据库驱动对参数值进行转义和安全处理。这意味着只要你的查询条件是通过ORM的参数绑定API传入的，注入就很难发生。但问题在于，ORM提供了大量灵活接口，其中不少接口允许你直接传入SQL片段或整条SQL字符串。比如MyBatis里的${}和#{}的区别，前者是直接字符串替换，后者才是预编译占位符。很多开发者图省事，在动态排序字段、表名、列名这些无法使用占位符的场景里用${}拼接，攻击者只要控制其中一个变量，就能改变整个SQL语义。
再比如JPA的JPQL和Hibernate的HQL，本身支持参数绑定，但如果你用字符串拼接的方式构造查询，然后交给EntityManager执行，框架并不会帮你拦截恶意内容。SQLAlchemy里同样存在text()函数和字符串拼接混用的情况，一旦把用户输入直接拼进text()的SQL字符串里，ORM的保护就形同虚设。所以最根本的原则是：凡是携带用户数据的部分，必须走参数绑定；凡是SQL结构本身需要动态变化的部分，必须使用白名单校验，绝不能直接拼接。
动态排序和动态表名字段名的正确处理
参数绑定只能解决值的问题，不能解决SQL标识符的问题。排序字段、分组字段、表名、列名这些内容在SQL语法里属于标识符，数据库驱动不会对它们做参数化处理。很多业务系统需要前端传一个排序字段或者排序方向，如果直接拼接到SQL里，攻击者可以传入类似“id; DROP TABLE users--”的内容。正确的做法是维护一个允许的字段映射表，前端传过来的值必须在这个映射表里找到对应项才使用，否则回退到默认值。比如前端传“username”，后端映射为“user_name”，前端传“createTime”，后端映射为“create_time”，任何不在映射表里的输入一律拒绝或使用默认排序。
对于表名和列名，白名单的严格程度要更高。如果业务上确实需要动态切换表，比如分表逻辑，也应当由后端根据业务规则计算出表名，而不是直接接收前端参数。实在无法避免时，可以对标识符做严格的格式校验，比如只允许字母、数字和下划线，并且必须以字母开头，同时还要用数据库特有的引用方式包裹，例如MySQL的反引号、PostgreSQL的双引号。但即便做了这些，仍然建议优先使用白名单，因为格式校验只能防住大部分注入，不能防住通过合法格式传入的恶意标识符。
ORM原生SQL接口的高危用法
几乎每个ORM框架都提供了执行原生SQL的能力，这是为了处理复杂查询和性能优化场景，但也是注入风险最高的地方。以MyBatis为例，XML映射文件里的SQL语句如果使用${}拼接参数，等于完全放弃了预编译保护。有些开发者认为${}只用于内部数据，但内部数据也可能被用户输入间接污染。例如某个参数从数据库读出后再拼进另一条SQL，如果这个字段当初就是用户提交的，攻击者就能通过存储型注入实现二次注入。
// 危险示例：MyBatis中使用${}直接拼接用户可控参数
SELECT * FROM users WHERE name = '${userName}'
// 安全示例：使用#{}进行参数绑定
SELECT * FROM users WHERE name = #{userName}
在Hibernate中，使用createNativeQuery或者createSQLQuery执行原生SQL时，同样要避免字符串拼接。正确的做法是使用带参数的Query接口，通过setParameter方法绑定值。JPA的EntityManager也有createNativeQuery方法，配合setParameter使用。SQLAlchemy中执行原生SQL时，推荐使用text()配合绑定参数，例如text("SELECT * FROM users WHERE name = :name")，然后通过params传入字典，而不是用字符串格式化或者f-string拼接。
批量操作和IN子句的陷阱
IN子句是另一个容易出问题的地方。很多开发者习惯把列表转换成逗号分隔的字符串再拼进SQL，比如前端传一个ID列表，后端用“1,2,3”的形式拼接。这种方式完全绕过了参数绑定，攻击者可以传入“1) OR 1=1--”之类的值。不同ORM框架对IN子句的支持方式不同，但都有安全的处理办法。MyBatis中可以使用foreach标签生成参数占位符，Hibernate和JPA中可以使用setParameterList或者直接将集合作为参数传入，SQLAlchemy中可以使用in_操作符配合列表参数。
// MyBatis安全处理IN子句 SELECT * FROM users WHERE id IN#{id}
需要注意的是，有些ORM框架在IN子句参数数量过大时会有性能问题，比如Oracle对IN列表的数量限制是1000个。这时候需要分批处理，但分批处理也要保持参数绑定，不能因为分批就改用字符串拼接。另外，如果IN子句里的数据来自用户输入，还需要对列表长度做限制，防止攻击者传入超大列表导致SQL语句过长或者数据库资源耗尽。
LIKE查询和通配符处理
LIKE查询本身不是注入点，但用户输入中的通配符可能改变查询意图。比如用户搜索“%”或者“_”，如果直接拼进LIKE条件，可能匹配出全表数据。更危险的是，有些开发者为了支持模糊搜索，会在后端用字符串拼接的方式构造LIKE条件，例如“'%” + keyword + “%'”，这就把参数绑定丢了。正确的做法是先用参数绑定传递用户输入，然后在SQL里使用CONCAT函数或者ORM提供的like方法，例如MyBatis中可以使用“LIKE CONCAT('%', #{keyword}, '%')”，Hibernate中可以使用Restrictions.like或者CriteriaBuilder的like方法，SQLAlchemy中可以使用like方法配合通配符。
如果用户输入里本身包含通配符，而业务上希望按字面意思匹配，就需要对通配符进行转义。不同数据库的转义方式不同，MySQL默认使用反斜杠，但可以通过ESCAPE子句指定转义字符。ORM框架通常不提供统一的转义方法，需要开发者根据数据库类型自行处理。不过大多数搜索场景下，用户输入通配符并不会造成安全漏洞，只是可能影响查询结果，所以优先级可以放低，但LIKE条件本身的参数绑定不能放松。
ORM框架的隐式SQL生成风险
ORM的自动SQL生成机制虽然方便，但也可能产生意想不到的注入面。以Hibernate为例，如果实体类的属性名或者映射的列名来自用户输入，在某些动态查询场景下可能被利用。比如使用Criteria API时，如果根据前端传的字段名动态调用Restrictions.eq，攻击者可以传入任意字段名，虽然不能直接注入SQL，但可能探测出数据库结构，属于信息泄露。更严重的是，如果使用Hibernate的HQL拼接，字段名直接拼进HQL字符串，攻击者可以构造恶意HQL，甚至调用数据库函数执行危险操作。
另一个容易被忽略的是ORM的级联操作和懒加载机制。攻击者可以通过构造特定的对象图，触发ORM生成大量SQL语句，造成数据库压力。这类问题严格来说不属于SQL注入，但属于ORM使用不当导致的安全风险。防范方法是限制前端传入的对象深度，对关联查询设置合理的fetch策略，避免根据用户输入动态构建复杂的对象图。
存储过程和函数调用中的参数处理
很多企业级应用会使用存储过程封装业务逻辑，ORM调用存储过程时同样需要参数绑定。有些开发者习惯用字符串拼接的方式构造CALL语句，这是非常危险的。以MyBatis为例，调用存储过程时可以使用select标签或者update标签，通过parameterType和parameterMap定义参数，框架会自动处理参数绑定。JPA中可以使用@NamedStoredProcedureQuery注解或者EntityManager的createStoredProcedureQuery方法，通过setParameter绑定参数。SQLAlchemy中可以使用callproc或者text()配合绑定参数。
需要特别注意的是，存储过程内部如果使用了动态SQL拼接，同样存在注入风险。ORM只能保证调用存储过程时的参数传递安全，无法控制存储过程内部的SQL构造。因此，存储过程内部的动态SQL必须使用数据库提供的参数化机制，比如MySQL的PREPARE语句、SQL Server的sp_executesql、Oracle的绑定变量。如果存储过程内部使用了EXEC或者EXECUTE IMMEDIATE拼接字符串，攻击者可以通过传入恶意参数实现注入。
ORM配置和日志中的敏感信息泄露
SQL注入的最终目的是获取数据，而ORM的配置和日志有时候会主动把敏感信息暴露出去。很多ORM框架支持打印SQL日志，方便开发调试，但如果日志级别设置不当，生产环境会把完整的SQL语句和参数值记录到日志文件里。这些SQL语句中可能包含用户密码、身份证号、手机号等敏感数据，一旦日志文件被攻击者获取，相当于直接拿到了数据库内容。更危险的是，有些ORM框架在日志中会输出DDL语句，包括建表结构和索引信息，这为攻击者提供了数据库结构的完整蓝图。
正确的做法是生产环境关闭SQL日志或者只记录SQL结构而不记录参数值，同时确保日志文件的访问权限严格控制。另外，ORM的配置文件中可能包含数据库连接信息，包括账号密码，这些配置文件不能放在Web可访问目录下，也不能提交到版本库中。很多数据泄露事件并不是通过SQL注入，而是通过配置文件泄露直接拿到了数据库权限。
框架版本和补丁管理
ORM框架本身也会存在安全漏洞，包括SQL注入漏洞。例如某些版本的Hibernate在处理特定HQL语法时存在注入绕过，某些版本的MyBatis在动态SQL解析时存在缺陷。这些漏洞通常会在安全公告中发布，并推出修复版本。很多企业使用ORM框架后长期不升级，导致已知漏洞被攻击者利用。因此，ORM框架的版本管理应当纳入安全运维体系，定期检查安全公告，及时升级到修复版本。同时，升级前需要在测试环境验证兼容性，避免因为升级导致业务功能异常。
除了框架本身，数据库驱动也需要关注。参数绑定的安全性最终由数据库驱动实现，如果驱动存在缺陷，ORM层面的防护也会失效。例如某些旧版本的JDBC驱动在处理特殊字符时存在转义绕过问题。保持数据库驱动和ORM框架的版本更新，是防止这类底层漏洞的必要措施。
代码审计和自动化检测
ORM使用不当导致的SQL注入往往比较隐蔽，因为代码里看不到明显的字符串拼接，问题可能出在某个动态查询方法或者原生SQL接口上。人工代码审查需要重点关注所有使用原生SQL、动态SQL、字符串拼接的地方，以及所有接收用户输入的参数流向。自动化检测工具可以帮助发现潜在的注入点，比如静态代码分析工具可以标记出使用${}的地方、直接拼接SQL字符串的地方、以及未使用参数绑定的原生查询。
动态测试同样重要，可以使用自动化扫描工具对应用进行模糊测试，输入各种注入payload，观察响应和数据库状态。对于使用ORM的应用，测试重点应该放在那些可能退化为字符串拼接的场景，比如排序参数、分页参数、过滤条件、导出功能等。渗透测试中，攻击者通常会先尝试常规注入payload，如果ORM防护严密，再尝试通过ORM特有的接口绕过，比如HQL注入、JPQL注入、以及ORM生成的SQL中的二次注入。
开发规范和安全培训
技术手段只能解决一部分问题，根本的防线在于开发规范和安全意识。团队应当制定明确的ORM使用规范，规定哪些接口可以用，哪些接口禁止使用，哪些场景必须使用白名单，哪些场景需要额外的安全评审。规范中应当包含具体的代码示例，让开发者知道正确写法是什么样。对于新加入团队的开发者，应当进行安全培训，重点讲解ORM防注入的原理和常见错误用法。
安全培训不能停留在理论层面，要用真实的攻击案例演示注入的危害。很多开发者认为ORM天然安全，只有亲眼看到通过一个排序参数就能拖出整个数据库，才会真正重视参数绑定。培训中还应当强调，安全不是某个人的责任，而是每个开发者的责任。代码评审时，安全相关的问题应当作为阻断项，不允许合入有注入风险的代码。
ORM框架确实大幅降低了SQL注入的风险，但前提是开发者始终使用参数绑定，并且在动态SQL场景下保持警惕。任何框架都有边界，框架的安全机制只在你正确使用它时才会生效。把ORM当成银弹，反而会让人放松对SQL注入的防范。真正安全的应用，是那些在每一层都坚持最小权限原则、在每一个输入点都做严格校验、在每一处SQL构造都使用参数化的应用。ORM只是工具，安全与否取决于使用工具的人。
