开发阶段防止SQL注入代码规范设置

SQL注入至今仍是Web应用最危险的漏洞之一，而在开发阶段建立代码规范，是从源头消灭这类风险成本最低、效果最彻底的手段。很多团队习惯在测试或上线前才做安全扫描，但此时数据层代码已经固化，修复往往涉及大量重构。真正有效的做法是把防注入规则直接嵌入日常编码标准中，让开发人员写每一条SQL时都有明确的约束可依。

先明确一个核心原则：所有外部输入在进入SQL语句之前，必须经过参数化处理或严格白名单校验。任何字符串拼接SQL的做法，无论业务逻辑看起来多么“安全”，都应视为违规。开发规范不能只写“禁止拼接SQL”这一句空话，而要具体到不同场景下的标准写法、禁止事项和审查要点。

在绝大多数数据库访问场景中，参数化查询（Prepared Statement）应当成为唯一允许的动态SQL执行方式。以Java JDBC为例，规范应明确要求使用PreparedStatement，并禁止Statement直接执行拼接后的字符串。代码示例如下：

// 正确：使用PreparedStatement
String customerName = request.getParameter("customerName");
String query = "SELECT account_balance FROM user_data WHERE user_name = ?";
PreparedStatement pstmt = connection.prepareStatement(query);
pstmt.setString(1, customerName);  // 参数绑定
ResultSet results = pstmt.executeQuery();

// 错误：禁止使用Statement拼接
String customerName = request.getParameter("customerName");
String query = "SELECT * FROM users WHERE name = '" + customerName + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(query);

规范中要强调，参数化查询不仅能防注入，还能提升数据库执行计划缓存效率。对于开发人员来说，这应当成为一种肌肉记忆，而不是需要反复提醒的安全补丁。

很多团队使用Hibernate、MyBatis、Entity Framework等ORM框架后，容易产生“框架已经防注入了”的错觉。实际上，ORM中的原生SQL接口和动态拼接查询仍然是高危区域。规范必须明确：在使用ORM时，优先使用框架提供的参数绑定机制；若必须使用原生SQL，同样要走参数化接口。

以MyBatis为例，规范应禁止在XML映射文件中使用${}进行值替换，而应使用#{}进行预编译参数绑定。${}是字符串直接替换，等同于拼接SQL，只有在表名、字段名等无法参数化的场景才允许出现，并且必须配合白名单校验。

// MyBatis正确写法
SELECT * FROM orders WHERE order_id = #{orderId}

// MyBatis危险写法，禁止
SELECT * FROM orders WHERE order_id = ${orderId}

代码审查时，凡是出现${}的地方都要逐一确认是否经过白名单过滤，否则一律打回修改。

参数化查询无法覆盖SQL语法中的标识符部分，比如表名、列名、排序方向（ASC/DESC）等。这些场景在报表系统、后台管理界面中非常常见。开发规范必须规定：任何来自用户输入且需要拼入SQL标识符位置的内容，必须通过服务端白名单映射来校验。

具体做法是，前端传过来的字段名或排序类型，不能直接拼进SQL。服务端应维护一个允许的字段集合，将用户输入映射到预定义的安全值。例如用户传入sortField=username，服务端代码应检查该值是否在允许列表["username","create_time","order_amount"]中，然后才将对应的列名写入SQL。任何不在白名单内的输入，直接返回参数错误或使用默认值。

// 正确：白名单映射
private static final Set ALLOWED_COLUMNS = Set.of("id", "username", "email", "create_time");
public List getUsersByOrder(String orderBy) {
    if (orderBy == null || !ALLOWED_COLUMNS.contains(orderBy)) {
        throw new IllegalArgumentException("Invalid column: " + orderBy);
    }
    return mapper.getUsersByOrder(orderBy);
}

这条规则要写入代码规范，并且代码审查时作为硬性检查项。很多SQL注入漏洞恰恰发生在排序、分页、分组这些容易被忽视的参数位置。

有些团队认为存储过程天然安全，因为SQL逻辑在数据库端定义。但实际上，如果存储过程内部使用动态SQL拼接，同样存在注入风险。开发规范应明确：存储过程内部若需要动态执行SQL，必须使用数据库提供的参数化执行能力，例如MySQL的PREPARE语句配合占位符，SQL Server的sp_executesql参数化调用。

同时，调用存储过程的应用代码也应使用参数传递，而不是把用户输入拼进调用字符串。规范中应给出各数据库平台下存储过程安全调用的标准示例，避免开发人员凭感觉编写。

参数化查询解决了SQL注入的主要攻击面，但开发规范不应只停留在这一层。输入验证可以在数据进入业务逻辑前拦截明显非法的内容。例如用户ID应当只允许数字，邮箱字段应当符合邮箱格式，名称字段长度应有限制。这些验证虽然不能替代参数化，但能有效降低攻击载荷到达数据库层的概率。

规范应要求所有外部输入在Controller层或Service层入口处进行类型、长度、格式和范围的校验。对于不符合规则的数据，直接拒绝请求。校验规则要集中管理，避免散落在各处导致标准不一。

输出编码则主要针对存储型XSS等二次攻击场景，虽然与SQL注入直接关系较小，但作为完整的安全编码规范，应当一并纳入。数据库读出的内容在回显到页面时，要根据上下文进行HTML编码、JavaScript编码或URL编码。

开发阶段就要规定统一的异常处理机制。数据库异常信息绝不能直接返回给前端。详细的SQL错误、表结构信息、数据库版本等内容，对攻击者来说是极有价值的情报。规范应要求捕获所有数据库相关异常，记录到服务端日志，并向用户返回模糊的通用错误提示。

同时，日志记录本身也要注意脱敏，避免将用户输入的完整SQL语句或敏感参数明文写入日志文件。日志中的SQL语句应使用占位符形式，参数值单独记录并做脱敏处理。

开发规范要落地，必须有配套的审查清单。每次代码合并前，审查人员应逐项核对以下内容：是否使用了Statement或字符串拼接SQL；MyBatis中是否出现${}且无白名单；动态表名字段名是否经过白名单映射；存储过程内部是否使用参数化执行；输入校验是否在服务端执行；数据库异常是否被统一处理且不向前端泄露细节。

这些检查项应集成到代码审查模板中，而不是依赖审查人员的个人经验。对于新加入团队的开发人员，入职培训中必须包含这套规范的详细讲解和实际案例演示。

规范写得再详细，最终执行还是靠人。开发阶段可以引入静态代码分析工具，在代码提交时自动扫描SQL注入风险模式。例如检测到Statement对象、字符串拼接SQL、MyBatis的${}用法时，直接在CI流水线中阻断构建。工具规则要与团队规范保持一致，并定期更新。

动态测试方面，可以在开发环境中定期运行自动化安全扫描，针对已知的注入测试向量进行验证。这些工具不能替代人工审查，但能显著降低遗漏概率。

开发规范还应包含数据库账号权限的约束。应用连接数据库的账号不应拥有DDL权限，也不应拥有超出业务需要的表访问权限。对于只需要读取的模块，使用只读账号；对于需要写入的模块，账号仅授予对应表的INSERT、UPDATE、DELETE权限。这样即使某个接口存在注入漏洞，攻击者也无法通过该连接执行DROP TABLE或访问其他敏感表。

这条规则需要在开发环境、测试环境和生产环境统一执行。很多团队在开发环境为了方便使用高权限账号，导致开发人员习惯了宽松的权限环境，上线后才发现权限配置不一致。

SQL注入的攻击手法和绕过技术一直在发展，开发规范也需要定期回顾和更新。每次出现新的漏洞案例或内部安全事件后，应分析原因，将新的防护要求补充到规范中。同时，随着技术栈变化，比如引入新的ORM框架、切换数据库、增加微服务模块，规范中的代码示例和检查项也要同步调整。

最终目标是让防注入成为开发流程中自然的一部分，而不是额外的安全负担。当每一位开发人员都能下意识地写出参数化查询、习惯性地对动态标识符做白名单校验时，SQL注入的生存空间就被压缩到了最低。