去年秋天，全攻一个电商网站的防宝后台被拖走了整整 300 万条用户订单。攻击者没用什么零日漏洞，典实只是战篇在一个旧版 Struts2 的 action 参数里塞了段 OGNL 表达式。运维团队直到三天后才发现异常——数据库里多了一条 admin 用户，全攻密码是防宝 123456。这种事每天都在发生，典实区别只在于你有没有察觉。战篇

Web 安全的全攻本质不是堆防火墙，是防宝理解数据从浏览器到数据库的完整路径。很多人一上来就背 OWASP Top 10，典实背完还是战篇不知道一个 SQL 注入怎么从 URL 参数打到 mysql 的 information_schema。我见过太多人把安全当运维的全攻附属品，结果就是防宝补丁永远慢半拍。

先看一个真实案例

某政务系统有个文件上传接口，典实前端校验了后缀名，后端只检查了 Content-Type。攻击者把 shell.php 改成 shell.php.jpg，再抓包把 Content-Type 改成 image/jpeg，直接传上去。更离谱的是上传目录有执行权限，访问 /upload/shell.php.jpg 时，Apache 的多后缀解析漏洞把 .jpg 当成了扩展名，实际执行的是 .php。这条链路上每一步都有修复机会，但没人做。

防御这类问题，核心就一句话：永远不要信任客户端提交的任何数据。白名单校验后缀名，重命名文件，把上传目录的脚本执行权限关掉。三行配置的事，偏偏要等被拖库才想起来。

SQL 注入为什么还没死

预编译能解决 90% 的注入问题，但现实中大量老系统还在拼接 SQL。我审计过一个内部 OA，登录逻辑是这样的：

String sql = "select * from users where username='" + name + "' and password='" + pwd + "'";

输入 ' or '1'='1 直接进后台。更麻烦的是这个系统用了 DBA 权限连数据库，攻击者可以 union select 出所有表名，再用 load_file() 读 /etc/passwd。从注入到提权，全程不到十分钟。

修复方案不复杂：换成 PreparedStatement，数据库账号降权，关掉 secure_file_priv。但很多团队卡在“业务不能停”上，最后选择加个 WAF 了事。WAF 能挡脚本小子，挡不住手工注入。

XSS 的战场在浏览器

反射型 XSS 越来越难打，因为现代框架默认转义。但存储型 XSS 依然猖獗，尤其是富文本编辑器。有个社区论坛允许用户发帖时带 HTML，过滤函数只删了 <script> 标签。攻击者用 <img src=x onerror=alert(document.cookie)> 就拿到了管理员 session。

防御 XSS 的关键是上下文感知的转义。HTML 属性里要转义引号，JS 变量里要转义反斜杠，URL 里要 encode。别自己写正则，用 DOMPurify 这类库。另外，给 Cookie 加上 HttpOnly，就算 XSS 成功了也偷不走 session。

CSRF 靠的是浏览器自动带 Cookie

一个银行转账接口，参数只有 to=xxx&amount=xxx，没有 token。攻击者做个钓鱼页面，里面藏个自动提交的表单，受害者一访问钱就转走了。防御方法很简单：加 CSRF Token，校验 Referer，或者把 SameSite 设成 Lax。但很多老系统就是不做，觉得“用户不会点陌生链接”。

我自己的习惯是，任何涉及状态变更的接口，必须带一次性 token。token 存在 session 里，表单提交时带上，服务端比对。多写二十行代码，省掉一堆扯皮。

文件包含和命令执行

PHP 的 include($_GET['page']) 是经典漏洞。攻击者传 ?page=../../../../etc/passwd 就能读文件，传 ?page=php://input 配合 POST 数据就能执行代码。修复方法是白名单，只允许包含指定目录下的文件，或者用 basename() 过滤路径。

命令执行更直接：system("ping " . $_GET['ip'])，输入 127.0.0.1; cat /etc/shadow 就完蛋。别用 system、exec、shell_exec，非要用的话，用 escapeshellarg() 把参数包起来。

我的观察

大部分入侵不是因为漏洞多高级，是因为基础没做好。补丁没打、权限没降、日志没看。安全不是买套设备就完事，是每个开发写代码时多问一句“这参数用户能控制吗”。攻防的差距，往往就在这一问上。