SQL注入漏洞必须通过参数化查询在数据库访问层修复，国密加密和访问控制无法替代；政府系统须100%禁用字符串拼接，强制使用PreparedStatement、PDO预处理或MyBatis的#{}占位符。
直接说结论：国密算法加密不能修复 SQL 注入漏洞，访问控制加固也不能替代参数化查询。把加密或权限当“解药”，反而会掩盖真正要动代码的地方，导致高危点持续裸奔。
SQL 注入漏洞必须在数据库访问层堵住，不是在传输或权限层
SQL 注入的本质是：用户输入被拼进 SQL 字符串后交由数据库执行。
哪怕你用 SM4 加密了 HTTP 请求体、用 SM2 签名了参数、甚至把数据库账户权限缩到只读，只要后端还存在类似这样的代码：
sql = "SELECT * FROM users WHERE id = " + request.GET.get('id')——攻击者就能通过 id=1 OR 1=1 绕过所有上层防护，直接操纵数据库语句。
- 国密算法（如
SM2/SM4）解决的是信道机密性与完整性，不干预 SQL 构造逻辑 - 访问控制（如 RBAC、IP 白名单、登录态校验）解决的是谁可以发起请求，不阻止恶意 SQL 执行
- 真正起效的只有：让数据库引擎明确区分「代码」和「数据」
政府类网站修复 SQL 注入的实操优先级
政府系统常见技术栈是 Java（Spring Boot + MyBatis）、PHP（ThinkPHP）、或 .NET（ASP.NET Core），修复必须按以下顺序落地：
-
强制禁用字符串拼接 SQL：全局搜索
Statement.execute、mysql_query(、db.execSQL(、DbContext.Database.ExecuteSqlRaw(等危险调用，全部替换 -
Java 项目统一用
PreparedStatement或 MyBatis 的#{}占位符（不是${}！后者仍会拼接） - *PHP 项目弃用
mysql_和mysqli_query拼接，改用PDO::prepare()+bindValue()** - .NET 项目禁用
SqlCommand.CommandText直接赋值，改用Parameters.AddWithValue()或命名参数
示例（Java + MyBatis）：
<!-- ✅ 安全 -->
SELECT * FROM t_notice WHERE status = #{status} AND dept_id = #{deptId}
<p><!-- ❌ 危险 -->
SELECT * FROM t_notice WHERE status = ${status} AND dept_id = ${deptId}国密和访问控制该用在哪儿？别用错地方
它们不是 SQL 注入的“修复项”，而是纵深防御中必须补上的环节，但前提是注入点已清零：
-
SM4加密应作用于：前端提交的敏感字段（如身份证号、手机号）在传输前加密，服务端解密后再进入业务逻辑 —— 防止中间人窃取明文，不防注入 -
SM2签名应作用于：关键操作（如公文发布、资金拨付）的请求体签名验证 —— 防篡改，不防 SQL 层污染 - 访问控制加固重点在：
- 数据库账号去特权化（禁用
DROP、CREATE、LOAD_FILE等高危权限） - 后端接口增加
@PreAuthorize("hasRole('GOV_ADMIN')")类注解 —— 但这只能拦请求，拦不住已认证用户的注入 payload
- 数据库账号去特权化（禁用
政府项目常犯的错：花两周配好
SM2签名网关，却留着一个未参数化的report/export?year=2025接口，攻击者登录后直接?year=2025 UNION SELECT password FROM sys_user—— 权限再严、加密再密，也救不了这行代码。
真正卡住政府类系统上线前验收的，从来不是“有没有上国密”，而是“所有带用户输入的数据库操作，是否 100% 走参数化”。其他都是锦上添花，唯独这一条是生死线。
