一句查询里的引号

数据库查询是把条件和指令写在一条语句里的语言，问题就出在这儿：如果用户的输入被直接拼进语句，那么输入里带的引号、注释符、连接词就会被数据库当成语法的一部分。本来只想查一条记录，结果条件被撑开，返回了整个表。这就是注入最朴素的形态。

它不需要攻击者有多高的水平，公开的工具可以自动完成探测、判断字段数、猜表名、导出数据这一整套动作。

进来之后能做什么

危害要分情况看，和数据库账号的权限直接相关。权限小的时候，可能只是把某张表的数据读走；权限大的时候，可以改数据、删表，甚至借助数据库自身的功能执行系统命令。还有一种容易被低估的情况：注入点出现在登录接口上，攻击者不需要密码就能构造出一个恒成立的判断，直接以管理员身份进入后台。

更麻烦的是被拿走的数据往往包含其他用户的信息。一次注入暴露的可能不只是当前站点的账号，如果数据库里存着手机号、地址或者证件信息，后续的骚扰和诈骗会一直持续下去。

几种常见的藏身之处

有的注入藏在查询参数里，有的藏在请求体里，还有的藏在请求头和 Cookie 里——后台从这些地方取用户标识去查权限，攻击者改了它就能越权。编码方式是绕过检测的常见手段：把关键字做地址编码、进制转换或者大小写混排，如果防护只做一次解码或者简单的字面匹配，就容易滑过去。

根治要靠参数化

正确做法是让数据和指令永远分开：查询语句里用占位符，参数通过独立通道传给数据库，这样输入里的引号只是数据的一部分，不再是语法。主流语言的数据库库都支持这种写法。存储过程、ORM 框架如果用对了也同样有效，但要注意拼接字符串的地方，很多框架也提供了直接执行原生语句的接口，滥用的地方就是漏点。

兜底和检查

不能只依赖一层。数据库账号按库授权，应用账号不给建库删表这类管理权限，即使被注入也拿不到别的业务数据。查询接口对返回行数和耗时做限制，避免一次请求把整张表拉出来。代码上线前用扫描工具覆盖主要接口，同时把防护日志里的拦截记录纳入日常查看，判断有没有人在持续试探。

还有一点常被忽略：报错信息要统一处理。数据库把语法错误直接吐回页面，等于免费给攻击者提供反馈，让猜测变得又快又准。

开发阶段能省的力气

注入类问题最适合在写代码的时候就消灭。查询条件用参数占位，不要让用户输入参与拼接，这一条能消掉大部分情况；排序字段、表名这类没法用参数的位置，就改成从白名单里选，而不是直接拼字符串。养成习惯之后，代码反而更短，因为不用再写转义的各种分支。

还有一个常见来源是管理后台的查询功能。筛选项多、拼装灵活，很容易一行行拼出语句，而这类页面往往只在登录后可用，开发时就觉得风险不大。实际上后台账号泄露并不少见，把后台查询也按公网接口的标准来写，能省掉后面很多麻烦。

上线前再扫一遍，重点看有没有拼接痕迹和详细错误提示。这两样同时出现，等于给猜测的人提供即时反馈。

很多站点所有功能共用一个数据库账号，权限还是最大的那种。一旦某个页面被注入，拿到的是整库权限，读写删随心所欲。按用途拆开账号，查询用的只给读，写入的只给必要的表，能显著压缩一次注入能造成的后果。

系统里原本就有的高权限账号不要拿来跑业务。它们的权限通常连配置文件都能改，一旦凭据泄露，影响远不止一个库。

改账号时注意连接池和配置文件里可能还留着旧凭据，改完要重启服务并确认真的连上了新账号，而不是只看修改记录。

再把错误提示统一收口，别把库名、字段名和语句片段带出去，整体才算完整。这些调整不涉及业务逻辑，改动小、见效快，值得早点做。