后台接口易成SQL注入突破口，因其默认信任内部访问，存在未绑定参数、整数型注入、低风险模块缺校验三类疏漏；防御关键在于切断注入路径而非增加校验。
管理员后台不是“更易被注入”，而是攻击者一旦得手，危害直接翻倍——因为后台通常绕过前端限制、直连高权限数据库账户、且输入点集中（如搜索框、ID参数、批量操作表单）。防御重点不在“加更多校验”，而在切断注入路径本身。
为什么后台接口常成SQL注入突破口
后台接口往往默认信任内部访问，导致三类典型疏漏：
- 未强制使用
prepare()或execute()绑定参数，仍用字符串拼接构造SELECT/UPDATE语句 - 对 URL 中的
id、status、sort等参数仅做类型转换（如int()），但未拦截形如1 OR 1=1的整数型注入 - 日志导出、数据同步等“非核心功能”接口，被当成低风险模块，跳过输入白名单校验
后台登录态校验不能替代SQL层防护
很多后台在入口做了 session 验证或 JWT 解析，但这只防未授权访问，不防已登录用户的恶意输入。只要 admin.php?user_id=123 这类接口还存在拼接逻辑，攻击者就能用 user_id=123%20UNION%20SELECT%20password%20FROM%20users 直接拖库。
关键判断点：只要 SQL 查询里出现 "' . $id . '" 或 "$id" 这类拼接，无论是否登录，都算裸奔。
后台专用的输入过滤策略
后台比前台更需“刚性过滤”，但不能靠简单替换单引号或分号——这些容易被编码绕过。应按字段语义分级处理：
- ID 类参数（
user_id、order_no）：强制走filter_var($id, FILTER_VALIDATE_INT)或数据库驱动的bind_param('i', $id)，拒绝一切非纯数字输入 - 状态/枚举类（
status=active）：限定白名单数组['active', 'disabled', 'pending']，不在其中则直接 400 - 搜索关键词（
q=xxx）：禁用LIKE拼接，改用全文索引或 Elasticsearch；若必须用LIKE，则对%、_、[等通配符做addcslashes($q, '%_[]')
最容易被忽略的后台注入点
开发者常盯着登录、用户管理这些显眼接口，却漏掉：
-
/api/export?table=users&fields=id,name,email——table和fields若未校验，可被改成table=users%20JOIN%20config - 富文本编辑器提交的
content字段，后台直接存入INSERT INTO posts (content)，没做任何转义 - 定时任务配置页的 Cron 表达式输入框，后端用
exec("crontab -l | sed ...")拼接 shell 命令，间接触发数据库命令执行
真正危险的从来不是“有没有校验”，而是“校验有没有覆盖所有动态拼接点”。后台代码越复杂，越要靠静态扫描工具（如 Semgrep 规则匹配 .*\.\$.* 在 SQL 字符串中）主动揪出隐藏拼接。
