注入从哪里开始？
不可信输入进入动态 SQL 结构，可能改变查询原意。风险取决于实际拼接位置与数据库语法，不能只靠输入里有没有某个关键字判断。[1]
083 / Web 与应用 / SQL Injection
这是一个名字，还是一条指令？
SQL 注入 · SQL Injection
搜索框接收的是数据。把输入直接拼进查询，数据库却可能把它当成指令的一部分。对照两种写法，看清参数绑定保护的那条边界。
开始探索 ↓7–10 分钟
动手实验 · 场景判断 · 实用检查
动手实验 · 场景判断 · 实用检查
卷纸比喻外部输入，守卫比喻应用。红色角色进入资料库，表现数据被误当成指令后的风险；这不是数据库的真实内部形态。
展开读图提示
读图提示
- 角色与机制
- 卷纸比喻用户输入，守卫比喻处理查询的应用，后方资料库比喻数据库。
- 风险在哪里
- 输入一旦被拼进 SQL 指令，红色小怪般的恶意片段就可能改变查询逻辑，读取或破坏数据。
- 防护与边界
- 使用参数化查询，把数据和 SQL 结构分开；再用最小数据库权限限制后果。图中展示的是防线失守。
本课任务 / SQL 注入
让查询结构由代码决定，让用户输入始终作为参数数据处理。
- 观察字符串拼接如何混淆结构与数据
- 对照模板和独立参数
- 解释参数化之外仍需处理的边界
亲手探索 / 不同条件，不同结果
同一份输入，经过两条不同的数据路径。
编辑虚构姓名、选择预设，再预测结果。模板与参数会分开显示；本页只解释指定教学样本，不连接数据库，也不是通用 SQL 解析器。
查询结构对照台
同一份输入，是姓名，还是查询的一部分？
虚构读书会按作者查找笔记。先预测，再对照两条路径：直接拼接字符串，以及固定模板后绑定参数。
尚未运行。先调整条件，再查看本地教学模型的结果。
再试一次：从普通姓名换到带单引号的姓名，再换到额外条件。哪一条路径的模板始终不变？表名为什么不能直接塞进同一个值参数？
OWASP：参数化查询与标识符边界（新窗口）随手查 / 把理解带回实际工作
理解机制之后，检查这些细节。
实验是简化模型。真实环境需要明确业务规则、验证失败路径，并持续维护配置与证据。
01 / 实用细节
用数据库接口绑定值
占位符的写法因驱动而异。关键是调用真正的参数绑定接口；先手工拼出字符串，再把它交给一个名为 prepare 的函数，并不能自动撤销已经发生的拼接。[1][2]
02 / 实用细节
动态标识符需要独立设计
排序列、表名等结构元素不应直接接收任意用户文本。让外部选项映射到代码里的固定标识符，并验证缺省、未知值与大小写等边界。[1]
03 / 实用细节
ORM 和存储过程也有原始入口
工具的安全默认值有帮助，但 raw SQL、动态拼接和存储过程内的动态执行仍需检查。审查数据最终到达数据库的方式，而不是只看框架名称。[1]
04 / 实用细节
输入校验服务业务规则
类型、长度和允许值校验能限制异常输入，却不能替代参数绑定。合法姓名本来就可能包含引号，不能把删除字符当成可靠的安全边界。[1]
05 / 实用细节
数据库权限限制最坏后果
应用账户只应拥有业务必需的权限；读取服务不应随意获得管理能力。权限收敛不能修复注入，但能降低单个缺陷带来的影响。[1]
06 / 实用细节
在获准环境测试实际查询链
回归既要检查普通值和特殊字符，也要验证未知排序选项、错误路径与原始查询入口。本页的符号模型不能代替驱动与数据库版本上的实际测试。[1][2]
从模拟，到验证
找一个获准的环境，实际检查一次。
勾选用于本页自查，不会自动标记整课已学会。练习与清单刷新后重置。
本页已检查 0 / 5 项
搜索接口如何更可靠地防 SQL 注入？
能解释原因，再标记学会。
小测结果同步错题本；“已学会”沿用原有本地学习记录。
资料与依据
- OWASP · SQL Injection Prevention ↗
参数化、动态标识符与最小数据库权限
- PostgreSQL · PQexecParams ↗
驱动参数与命令文本分离的具体接口实例
本页场景、人物与数据均为教学示例。互动选择不会上传；收藏、已学会与错题沿用当前浏览器本地存储。来源正文核对日期：2026-10-08。