sql注入攻击 字符串

一个登录框，入攻输入 ' or 击字'1'='1，密码随便敲，符串回车。入攻后台可能就放行了。击字这不是符串电影情节，是入攻每天发生在互联网角落的真实事故。字符串拼接SQL语句，击字是符串这种攻击的命门。

开发者图省事，入攻常写这样的击字代码：SELECT * FROM users WHERE name='$username' AND pass='$password'。用户输入被直接塞进SQL语句，符串像把生肉丢进绞肉机。入攻攻击者只需构造闭合引号的击字字符串，就能改变整条语句的符串逻辑。你输入admin'--，注释符把后面的密码校验吞掉，查询变成只验证用户名。更狠的，用' UNION SELECT * FROM cards--，能把别的表数据拖出来。

字符串注入的核心，在于引号闭合和注释符利用。数据库把单引号当作字符串边界，攻击者输入一个单引号，就打破了边界。再加两个单引号或者注释符，就能让原语句“断腿”。MySQL里#和-- （后面有空格）是注释，SQL Server用--，Oracle用--。不同数据库细节不同，但原理一致：让数据库解析你构造的假语句。

我见过一个真实案例。某小公司后台管理系统，搜索框里输入商品名。后端用字符串拼接查询库存。安全测试员输入%' AND 1=1 UNION SELECT username,password FROM admin--，半小时后，管理员明文密码躺在他桌面上。那密码居然是123456。你说这算谁的锅？拼接代码的，还是设弱密码的？

最气人的是，有些老系统到现在还在用字符串拼接。开发说“我们做了过滤”，过滤掉or、and、select这些关键词。但绕过手段多得像地铁口的传单：大小写混合Or、SeLeCt，用注释符分割sel/**/ect，用十六进制编码0x6f72代表or。过滤黑名单就像拿筛子挡洪水，总有漏网之鱼。

根本解法不是过滤，是预编译。参数化查询把SQL结构和数据分开，用户输入永远被当作字符串字面量，而不是可执行代码。就像把刀和手隔开，你输入' or '1'='1，数据库只会觉得这是个奇怪的搜索词，不会执行。Java的PreparedStatement、PHP的PDO、Python的cursor.execute带占位符，都是干这个的。可惜，很多教材还在教老掉牙的拼接写法。

字符串注入的根子，是信任用户输入。你让用户填手机号，他填'; DROP TABLE users;--，你就该明白：这世上没有“正常用户”这回事。攻击者比你更懂你的数据库，他们测试每个输入框，就像试衣间里的贼，挨个口袋摸。

写代码时多花十分钟用参数化，比事后被拖库跪求用户原谅划算得多。毕竟，字符串可以拼接，信任不能拼接。数据库里存的是数据，不是用户输入的命令——这个边界，得靠代码守死。