SQL注入因字符串拼接SQL且未过滤输入而发生，可致登录绕过、全表拖库、敏感数据泄露或删库；防御须用参数化查询，禁用拼接，动态对象需白名单校验。
SQL注入攻击的核心，是把用户输入当成了SQL代码来执行。
为什么能注入？关键就两点
一是程序用字符串拼接方式构造SQL语句，比如：
red">"SELECT * FROM users WHERE username = '" + input + "'"
二是没对用户输入做任何过滤或转义，让单引号、分号、注释符这些特殊字符直接进了SQL里。
只要这两个条件同时满足，攻击者就能通过输入破坏原有查询逻辑。
典型危险SQL示例及后果
以下都是真实场景中极易出问题的写法：
-
登录绕过：用户输入用户名为 admin' -- ，原查询变成
SELECT * FROM users WHERE username = 'admin' -- ' AND password = 'xxx'
后半段被注释掉，密码校验彻底失效。 -
全表拖库：URL参数传入 id=1 OR 1=1，查询变成
SELECT * FROM articles WHERE id = 1 OR 1=1
条件恒真，返回整张表所有记录。 -
联合查敏感数据：输入 admin' UNION SELECT credit_card FROM payments --
可能直接把银行卡号拼进正常结果页里返回给攻击者。 -
删库跑路：若后端允许堆叠查询（如MySQL默认配置），输入 1; DROP TABLE users; --
就可能在一次请求里执行多条命令，直接清空用户表。
哪些地方最容易中招
凡是用户能填、能改、能传的地方，都可能是入口点：
- 登录/注册表单的用户名、密码、邮箱字段
- 搜索框、商品筛选条件、分页参数（如 ?page=2&sort=name）
- URL中的GET参数（?id=5）、POST提交的JSON字段
- HTTP头里的Referer、User-Agent，甚至Cookie值
一句话防御原则
永远不要用字符串拼接拼SQL。该用参数化查询（PreparedStatement、?占位符）就用，该用ORM安全方法就用。对动态表名、列名等极少数无法参数化的场景，必须白名单校验，不能靠简单替换单引号来“过滤”。
