```html

去年秋天，漏洞一个做外贸的分析朋友找我，说他的漏洞独立站被Google标了“该网站可能被入侵”。我打开首页，分析表面正常，漏洞但右键查看源码，分析页面底部多了一段没见过的漏洞<script src="http://45.32.xx.xx/t.js"></script>。那个IP指向一台荷兰的分析VPS，脚本内容只有一行：动态生成一个隐藏的漏洞iframe，指向一个博彩页面。分析这就是漏洞典型的Web漏洞利用后的挂马行为——攻击者没改数据库，没删文件，分析只在模板里加了一行外链。漏洞

漏洞从哪进来的分析？他用的是一套三年前买的PHP商城源码，后台登录页没有验证码，漏洞也没有登录失败次数限制。攻击者用Burp Suite跑了一个两万条的弱口令字典，撞出了admin的密码——admin123。登录后台后，直接编辑了页脚模板。整个过程没用到什么高级0day，就是最基础的暴力破解加后台功能滥用。

Web站点的漏洞，很多不在代码本身，而在“信任边界”的模糊。用户输入被当成代码执行，这是XSS。用户输入被当成SQL指令拼接，这是注入。用户上传的文件被当成脚本运行，这是文件包含或RCE。去年一个教育平台被拖库，起因是搜索框的keyword参数直接拼进了SELECT * FROM articles WHERE title LIKE '%$keyword%'。攻击者提交' UNION SELECT 1,2,3,4,5-- -，页面回显了数据库版本。接着用load_file()读到了/etc/passwd。再接着，用INTO OUTFILE写了一个webshell到网站根目录。一个搜索框，最终变成服务器控制权。

文件上传的漏洞更直接。很多站点只在前端用JS判断后缀名，后端收到文件后不检查MIME，也不重命名。攻击者把shell.php改成shell.php.jpg，抓包改回shell.php，上传成功。访问/uploads/shell.php，直接执行系统命令。我见过一个CMS，上传目录甚至允许执行PHP，而管理员三年没改过默认的uploads路径。

逻辑漏洞容易被忽略，但破坏力不小。某电商站点的优惠券接口，前端传coupon_id=1001，后端直接根据ID发券，不校验用户是否已领取。攻击者写个循环，从1001到2000，领了两千张满减券。还有密码找回，验证码是四位数字，没有次数限制。用Python写个脚本，十分钟就能爆破出正确验证码，重置任意用户密码。

这些漏洞的共性是：开发者假设“用户会按正常流程操作”。但攻击者不会。他们会改参数、重放请求、绕过前端校验、猜测未公开的接口。一个登录框，正常用户输账号密码，攻击者输' or 1=1-- -。一个图片上传，正常用户传JPG，攻击者传.htaccess加shell.gif。

修复思路不复杂。所有数据库查询用参数化，别拼字符串。文件上传白名单后缀，重命名成随机字符串，存储目录禁止脚本执行。后台登录加验证码和失败锁定。敏感操作加CSRF token。但现实是，很多站点跑着十年前的开源程序，补丁没人打，后台路径还是/admin，数据库密码还是root。漏洞分析到最后，往往不是技术问题，是维护问题。

我习惯用Burp Suite的主动扫描跑一遍目标，再手动测几个点：登录处的SQL注入、搜索处的XSS、上传处的后缀绕过、API的越权。工具能发现六成问题，剩下的四成靠经验——比如看到?id=1就试试?id=1'，看到?file=index就试试?file=../../etc/passwd。Web漏洞没那么神秘，多数时候是开发者少写了一个htmlspecialchars()，或者少加了一个preparedStatement。

```