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