网站后台操作防SQL注入专项安全加固

后台登录入口、参数拼接的查询、文件上传回调、API接口，这些位置十有八九都存在SQL注入风险。很多开发者以为加了参数化查询就万事大吉，但实际操作中，拼接SQL的习惯、动态排序字段、模糊查询、IN条件拼接，仍然大量存在。更隐蔽的是，有些人只在登录处做了过滤，却在后台的列表筛选、导出、批量删除功能里直接拼接用户输入，注入往往就发生在这些“不起眼”的功能模块里。加固不是装个WAF就完事，必须从代码层、数据库层、权限层同时下手。

后台操作和前台不同，后台功能多、权限复杂，很多查询需要动态拼接条件。比如商品列表的筛选，可能同时存在按名称模糊搜索、按分类筛选、按时间排序、按状态过滤。开发者为了方便，常常写成类似下面的代码：

String sql = "SELECT * FROM product WHERE 1=1";
if(name != null && !name.isEmpty()){
    sql += " AND name LIKE '%" + name + "%'";
}
if(categoryId != null){
    sql += " AND category_id = " + categoryId;
}
if(orderBy != null){
    sql += " ORDER BY " + orderBy;
}

这段代码里，name、categoryId、orderBy三个参数全部存在注入风险。name虽然放在LIKE里，但单引号闭合后照样可以注入；categoryId如果前端传的是字符串，攻击者可以直接提交“1 OR 1=1”；orderBy更是典型的高危点，因为排序字段无法参数化，很多人直接拼接，攻击者可以构造“price DESC; DROP TABLE product;--”这类语句。后台的导出功能也经常使用类似逻辑，导出的查询条件往往和列表筛选共用一套拼接代码，一处注入，数据就可能被整表拖走。

所有带用户输入的SQL，第一原则是使用预编译语句和绑定参数。以Java的JDBC PreparedStatement为例：

String sql = "SELECT * FROM product WHERE name LIKE ? AND category_id = ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setString(1, "%" + name + "%");
ps.setInt(2, categoryId);
ResultSet rs = ps.executeQuery();

这样做可以杜绝绝大多数通过引号闭合进行的注入。但要注意，PreparedStatement只能绑定值，不能绑定表名、字段名、排序方向、LIMIT的数值等SQL语法结构。后台常见的“自定义列排序”“动态选择显示字段”功能，如果直接把前端传来的字段名拼进去，参数化查询也救不了。对于这类场景，必须使用白名单校验。例如排序字段只允许“id、name、price、create_time”这几个固定值，排序方向只允许“ASC”和“DESC”，任何不在白名单内的输入直接拒绝或使用默认值。

后台登录是注入的高发区。很多人认为登录只查用户名和密码，风险不大，但实际上登录处的SQL注入往往能绕过密码验证。典型的错误写法是：

String sql = "SELECT * FROM admin_user WHERE username = '" + username + "' AND password = '" + password + "'";

攻击者输入用户名“admin' --”，密码随便填，SQL变成“SELECT * FROM admin_user WHERE username = 'admin' --' AND password = 'xxx'”，注释符把后面的密码判断直接去掉，轻松登录后台。即使密码做了MD5加密，如果拼接的是加密前的字符串，注入依然成立。正确的做法是使用参数化查询，并且密码在服务端进行不可逆加密后再比对。更进一步，后台登录接口应该限制错误尝试次数，连续失败后锁定账号或要求验证码，防止注入成功后进一步爆破。

权限校验的SQL也不能忽视。很多后台使用“用户-角色-权限”模型，查询权限时可能拼接角色ID或用户ID。如果这些ID来自前端隐藏域或Cookie，攻击者可以修改后提交，造成越权。所有涉及权限判断的查询，必须从服务端会话中获取当前用户身份，不能信任客户端传来的任何身份标识。

有些后台系统使用存储过程封装业务逻辑，认为存储过程比拼接SQL安全。实际上，存储过程内部如果使用EXEC或sp_executesql执行动态拼接的字符串，注入风险一样存在。例如：

CREATE PROCEDURE SearchProduct
    @keyword NVARCHAR(100)
AS
BEGIN
    DECLARE @sql NVARCHAR(MAX)
    SET @sql = 'SELECT * FROM product WHERE name LIKE ''%' + @keyword + '%'''
    EXEC(@sql)
END

这种写法在存储过程内部拼接字符串再执行，参数化完全失效。正确的做法是使用sp_executesql并绑定参数：

CREATE PROCEDURE SearchProduct
    @keyword NVARCHAR(100)
AS
BEGIN
    DECLARE @sql NVARCHAR(MAX)
    SET @sql = 'SELECT * FROM product WHERE name LIKE @kw'
    EXEC sp_executesql @sql, N'@kw NVARCHAR(100)', @kw = '%' + @keyword + '%'
END

另外，存储过程的执行权限应该严格控制。后台应用连接数据库的账号，不应拥有创建存储过程、修改表结构、执行系统命令等高权限。很多注入攻击在获取数据后，会尝试调用xp_cmdshell等扩展存储过程来执行系统命令，如果数据库账号权限过大，服务器就彻底沦陷。

后台系统使用的数据库账号，应该与应用前台账号分离，并且只授予必要的SELECT、INSERT、UPDATE、DELETE权限。不要使用sa、root这类超级管理员账号连接数据库。对于后台的导出、备份功能，如果确实需要更高权限，可以单独使用一个受限的只读账号，或者通过存储过程封装，禁止直接执行任意SQL。

数据库本身的配置也要做安全加固。关闭不必要的扩展存储过程，限制远程连接IP，开启数据库审计日志。以MySQL为例，可以在配置文件中设置：

[mysqld]
skip-symbolic-links
local-infile=0
secure-file-priv=/var/lib/mysql-files

local-infile=0可以防止攻击者利用LOAD DATA LOCAL INFILE读取服务器文件，secure-file-priv限制文件导入导出的目录，防止通过SQL注入写入webshell。SQL Server则要禁用xp_cmdshell、sp_OACreate等危险存储过程，并定期检查数据库账号的权限变更。

虽然参数化查询是防注入的核心，但输入过滤仍然有必要，尤其是针对那些无法参数化的场景。过滤的原则是“白名单优先，黑名单补充”。对于数字类型的参数，必须强制转换为整数，任何非数字字符直接拒绝。对于字符串类型，除了参数化绑定，还可以在应用层做长度限制和字符集校验，过滤掉控制字符和特殊编码。

需要注意的是，输入过滤不能替代参数化查询。有些人只做过滤不做参数化，比如把单引号替换成两个单引号，或者过滤掉“SELECT”“UNION”等关键词，这种做法很容易被绕过。攻击者可以使用十六进制编码、双重URL编码、大小写混写、注释符分割等方式绕过关键词过滤。正确的顺序是：先做类型校验和格式校验，再用参数化查询绑定值，最后在输出到页面时做HTML编码，防止存储型XSS和注入的联合攻击。

后台的富文本编辑器、文件上传功能也要纳入防注入范围。富文本内容虽然不直接拼SQL，但如果存储后在其他查询中被拼接使用，同样可能触发注入。文件上传的回调接口如果包含文件名或路径参数，必须进行严格的白名单校验，禁止包含SQL关键字和特殊字符。

现在很多后台采用前后端分离架构，前端通过API调用后端接口。API接口的注入风险比传统表单提交更高，因为API通常直接接收JSON或XML格式的数据，开发者容易忽略对嵌套字段的校验。例如一个JSON请求：

{
    "filter": {
        "name": "admin' OR '1'='1",
        "categoryId": "1 OR 1=1"
    },
    "orderBy": "price; DROP TABLE product;--"
}

后端如果直接将这些字段拼接到SQL中，注入就会发生。API接口的加固要做到以下几点：第一，所有入参必须有明确的类型定义和格式校验，数字字段必须是数字，字符串字段限制长度和字符集；第二，排序、分组、字段选择等无法参数化的参数，必须使用服务端定义的白名单映射，前端只传标识符，不传实际字段名；第三，API接口要启用统一的异常处理，SQL错误信息不能直接返回给前端，防止攻击者通过报错信息获取数据库结构。

很多后台系统使用Hibernate、MyBatis、Entity Framework等ORM框架，认为框架自动处理了SQL注入。实际上，ORM框架在大多数情况下确实会使用参数化查询，但一旦使用原生SQL或动态SQL标签，风险就会重新出现。以MyBatis为例，使用${}拼接参数时，注入风险极高：

    SELECT * FROM product WHERE name LIKE '%${name}%'

这里的${name}是直接字符串替换，没有任何预编译保护。必须改为#{}：

    SELECT * FROM product WHERE name LIKE CONCAT('%', #{name}, '%')

对于动态排序、动态表名等场景，MyBatis中无法使用#{}，此时必须在Java代码层做白名单校验，校验通过后再用${}拼接，并且拼接的值必须来自服务端定义的常量集合，不能直接使用前端传入的原始值。Hibernate的HQL和Criteria查询也要避免使用字符串拼接，尽量使用命名参数或位置参数。

防注入不能只靠事前防御，事中监控和事后追溯同样重要。后台系统应该记录所有SQL执行日志，尤其是登录、查询、导出、删除等敏感操作。日志中要包含用户ID、IP地址、请求参数、执行时间、SQL语句（脱敏后）等信息。一旦发现异常查询，比如短时间内大量包含“UNION”“SELECT”“OR 1=1”等关键字的请求，立即触发告警。

数据库层面可以开启慢查询日志和错误日志，关注频繁报错的SQL语句。很多注入尝试会触发数据库语法错误，通过分析错误日志可以发现攻击痕迹。应用层可以部署轻量级的入侵检测规则，对请求参数中的SQL关键字、注释符、编码绕过特征进行实时检测，发现可疑请求直接阻断并记录。

应急响应方面，一旦确认发生SQL注入，第一步是立即下线相关功能或接口，切断攻击入口；第二步是分析日志确定影响范围，检查数据是否被篡改或泄露；第三步是修复代码漏洞，重新上线前进行回归测试；第四步是修改数据库账号密码，检查是否有新增的数据库账号或异常权限变更。如果攻击者已经获取了服务器权限，还需要对服务器进行全面排查，防止后门残留。

安全加固不是一次性的工作，后台功能迭代频繁，新开发的模块很容易引入新的注入点。建议建立代码审计制度，每次上线前对涉及数据库操作的代码进行安全审查，重点检查字符串拼接、动态SQL、存储过程、ORM原生查询等高风险代码。可以使用静态代码扫描工具辅助检测，但工具不能替代人工审查，很多逻辑复杂的注入点需要人工分析数据流才能发现。

渗透测试是验证加固效果的有效手段。可以定期邀请安全团队对后台系统进行黑盒或灰盒测试，模拟攻击者的手法尝试注入。测试范围要覆盖所有后台功能模块，包括登录、列表筛选、导出、批量操作、API接口、文件上传回调等。测试过程中发现的漏洞要建立跟踪机制，修复后复测，确保闭环。

后台防SQL注入的核心是“参数化查询+白名单校验+最小权限+日志监控”的组合策略。单纯依赖某一项措施都容易留下缺口。开发者要改变“后台只有内部人员使用，风险不大”的错误观念，实际上后台一旦被注入，造成的损失往往比前台更大，因为后台拥有更高的数据权限和系统权限。把每一项数据库操作都当作不可信输入来处理，才能从根本上降低注入风险。