后台管理系统之所以特别容易被SQL注入盯上，核心就在于这类系统往往有大量动态查询接口，开发时又常常直接拼接用户输入，再叠加高权限数据库账号，一旦出问题，影响通常不小。

真正要把风险压住，所有用户可控输入——无论是GET、POST、JSON，还是URL路径参数——都得强制走参数化查询。

而像ORDER BY、分页、模糊搜索、导出这类高危场景，不能只靠“差不多安全”，必须配合白名单校验或范围限制。

同时，数据库权限要尽量收紧，错误回显也要关闭，这才是基本防线。

后台管理系统为什么特别容易被SQL注入

因为后台通常有大量动态查询接口，比如用户搜索、日志筛选、权限批量修改。

开发时又容易为了“快速上线”，直接拼接 username、order_id、status 等参数进 SQL。

同时，后台常使用高权限数据库账号连接。一旦被攻破，后果通常比前端接口严重得多。

必须用参数化查询，而不是字符串拼接

所有涉及用户可控输入的 SQL 执行点，都得走参数绑定。

这不仅包括 GET 查询参数、POST 表单、JSON body，也包括 URL 路径片段，例如 /api/users/123 中的 123。

常见开发语言的安全写法

• Java 用 PreparedStatement，别用 Statement + String.format 或 + 拼接
• Python（PyMySQL / sqlite3）用 %s 或 占位符，不要用 f"SELECT * FROM users WHERE id = {user_id}"
• PHP（PDO）用 prepare() + execute()，禁用 mysql_query() 和 mysqli_query() 直接传参
• Node.js（mysql2）用 pool.execute('SELECT * FROM logs WHERE type = ', [type])，别用模板字符串

注意：MyBatis 中必须用 #{} ，${} 是字符串替换，等同于拼接，绝对不能用于用户输入字段。

后台管理特有的高危场景要单独加固

这些地方最容易漏防，也是攻击者首选入口。

• ORDER BY 字段名 —— 用户可能传 sort=username，但字段名无法参数化，必须白名单校验：if sort not in ['username', 'created_at', 'status']: raise ValueError
• 分页 LIMIT 参数 —— offset 和 limit 必须转成整数并做范围限制（如 max limit=100），防止 limit 1,999999999 扫库
• 多条件模糊搜索 —— 如“关键词匹配用户名或邮箱”，不要用 LIKE '%'+kw+'%'，改用全文索引或 ES；若必须 LIKE，只允许前缀匹配 LIKE +'%' 并对 kw 做长度截断（如 ≤50 字符）
• 导出 Excel 的查询 —— 后台常为“方便”复用前端搜索逻辑，结果把未过滤的用户输入直接喂给 DAO 层，必须独立走参数化路径

权限和错误信息不能省略

后台系统连库账号权限过大、报错信息泄露表结构，会让一次小漏洞变成全库沦陷。

• 数据库账号只授予 SELECT、UPDATE、INSERT 等必要权限，禁用 DROP、CREATE、LOAD_FILE、EXECUTE
• 关闭数据库错误回显（如 MySQL 的 show_errors=OFF），生产环境 Web 框架也要关掉调试模式，避免把 Unknown column 'xxx' in 'where clause' 这类信息暴露给前端
• 日志里记录可疑 SQL（如含 UNION SELECT、OR 1=1、SLEEP( 的请求），但别记原始参数值，只记脱敏后的哈希或标识

真正容易出问题的地方

真正难的不是写对一条 prepare，而是确保所有分支路径都没绕过参数化。

尤其是异常处理、导出、批量操作、历史代码遗留接口，最容易成为漏点。

后台越“灵活”的功能，越要警惕它背后那条没加问号的 SQL。

《夸克》非常好用的免费AI浏览器

下载APP查看