2019年夏天，漏洞某电商平台的攻击安全团队在凌晨三点收到告警：一个订单接口的响应时间突然从80毫秒飙到4秒。排查后发现，漏洞攻击者正在用SQL注入批量拖取用户手机号。攻击他们没攻破防火墙，漏洞也没绕过WAF，攻击只是漏洞在一个看似无害的“订单备注”参数里塞进了一段精心构造的payload。

SQL注入算得上Web漏洞里的攻击老面孔了。原理不复杂——后端把用户输入直接拼进SQL语句，漏洞输入里的攻击引号、分号、漏洞注释符就成了攻击者的攻击武器。有人觉得参数化查询普及后这问题该绝迹了，漏洞但现实是攻击，老系统改不动，漏洞新框架用错ORM照样中招。我见过一个团队用MyBatis的${ }代替#{ }，结果搜索框直接变成数据库浏览器。

XSS比SQL注入更隐蔽。它不直接碰数据库，而是把恶意脚本塞进页面，等别的用户来踩。存储型XSS最阴——攻击者把脚本写进评论区，每个访问者都中招。反射型则靠钓鱼链接，URL参数里藏一段<script>，服务器原样吐回页面就执行了。很多人以为转义了<和>就万事大吉，但属性里的onmouseover、javascript:伪协议、甚至CSS里的expression()都能绕过。我试过在一个老站点的搜索框输入"><img src=x onerror=alert(1)>，弹窗出来的时候，旁边的前端同事脸都绿了。

文件上传漏洞的破坏力往往被低估。开发者只检查了Content-Type，攻击者改个请求头就能传.php文件。更离谱的是有些站点用黑名单过滤，禁了.php却忘了.phtml、.php5，甚至.htaccess。上传目录如果还能执行脚本，那就等于把服务器钥匙递出去了。某次渗透测试里，我传了个.user.ini，把auto_prepend_file指向图片马，直接拿到shell。防守方后来加了open_basedir，但那是后话了。

CSRF利用的是浏览器自动带Cookie的机制。用户登录了银行网站，然后点开攻击者构造的页面，里面一个隐藏表单往转账接口提交请求——钱就没了。很多人说SameSite Cookie能防住，但老浏览器不支持，而且有些业务跨站请求是刚需。我见过一个投票系统，用GET请求投票，攻击者放个<img src="vote?id=123">就刷票了。防御得靠Token，但Token要是没绑定用户会话，照样白搭。

SSRF这几年越来越常见。攻击者让服务器去请求内网地址，http://169.254.169.254/latest/meta-data/这种云元数据接口一抓一个准。某次代码审计发现，一个图片加载功能直接把URL参数传给file_get_contents，没做任何限制。我改成http://127.0.0.1:6379，Redis的未授权访问就暴露了。修复方案要么白名单域名，要么禁掉file://、gopher://这些协议，但开发经常图省事只过滤localhost，用127.0.0.1或0.0.0.0就绕过去了。

命令注入、XXE、反序列化……漏洞类型列不完。核心就一条：永远别信用户输入。但“别信”不是加个htmlspecialchars就完事——得看输入进了什么上下文。SQL里要参数化，HTML里要按位置转义，命令里要白名单，URL里要校验协议。我见过太多团队在WAF上堆规则，结果一个%00截断就穿过去了。安全不是加层壳，是改代码。

凌晨那家电商最后怎么处理的？他们没换WAF，而是把那个接口的SQL改成了预编译，加了参数类型校验，顺便把错误信息从“SQL syntax error near…”改成了“系统繁忙”。攻击者第二天又来了，扫了半小时，什么也没拿到。