Google Gruyere：一个故意“漏成筛子”的练习场

它不是一个真实产品，却比很多真实产品更能教会你什么是漏洞 Web 漏洞。

打开 Gruyere 的和防首页，你会看到一个极其简陋的应用御留言板。没有花哨的漏洞 UI，没有用户头像，和防连 CSS 都像是应用御 1998 年写的。但就在这个“破站”里，漏洞藏着 XSS、和防路径遍历、应用御CSRF、漏洞SQL 注入、和防信息泄露——几乎你叫得上名字的应用御 Web 漏洞，它都有。漏洞Google 把它放在 google-gruyere.appspot.com 上，和防不是让你去黑别人，而是让你在自己的沙箱里，亲手把站点拆得七零八落。

我第一次玩 Gruyere 的时候，卡在了一个叫 upload 的功能上。它允许你上传文件，但文件名过滤得很随意。我试着传了一个 .html 文件，里面塞了一句 <script>alert(1)</script>，结果服务器原样返回，浏览器直接弹窗。这就是最经典的存储型 XSS——恶意脚本被永久存进了服务器，每个访问那个文件的人都会中招。Gruyere 的代码里，这个上传接口没有做任何 MIME 类型检查，也没有对文件名做路径规范化。你甚至可以用 ../../ 跳出上传目录，覆盖服务器上的其他文件。

防御这种事，说复杂也复杂，说简单也简单。Gruyere 的官方文档里给了每个漏洞的修复建议，但很多人懒得看。我试着手动修了几个：上传文件时，用白名单限制扩展名，再用 os.path.basename() 把文件名里的路径符号全砍掉；输出用户内容时，一律走 HTML 转义，把 < 变成 <。改完再跑一遍攻击脚本，弹窗没了，路径也跳不出去了。但别高兴太早——Gruyere 里还有一个 CSRF 漏洞，你修了上传，攻击者照样能通过一个伪造的表单，让已登录的用户在不知情的情况下发帖。

CSRF 的防御更依赖架构。Gruyere 的留言板没有 token，任何第三方页面都能构造一个 POST 请求，把留言内容改成“我是猪”。要堵住它，你得在每个表单里塞一个随机 token，服务器端校验这个 token 是否匹配。听起来简单，但如果你忘了在 GET 请求里也加校验，攻击者还是能用 <img> 标签发起请求。Gruyere 故意没做这个，就是让你体会一下“少写一行代码，多出一个洞”的滋味。

还有一个容易被忽略的点：错误信息。Gruyere 在 SQL 注入失败时，会把完整的数据库报错直接吐回浏览器。攻击者看到 SQLITE_ERROR: no such column: foo，就知道表名和列名了。防御方法？把错误日志写到服务器端，前端只返回“操作失败”。但很多开发者觉得报错信息越详细越好，方便调试——上线了也不改。Gruyere 就是这种坏习惯的放大版。

玩到最后，你会发现 Gruyere 的漏洞列表其实是一份“反面教材清单”。每个漏洞都对应一个常见的开发疏忽：信任用户输入、忘记转义、不做权限校验、把安全寄托在“没人会这么干”上。Google 没有把它包装成一个完美的教学工具，它粗糙、直接，甚至有点故意气人——你明明知道那里有个洞，但就是得自己动手才能补上。

如果你刚学 Web 安全，别一上来就去啃 OWASP Top 10 的 PDF。先花一个下午把 Gruyere 打通，用 Burp Suite 抓几个包，手动注入几条 SQL，再试着把漏洞一个个修掉。那种“原来如此”的感觉，比读十篇论文都管用。当然，修完记得把代码删了——别把练习场的漏洞带到真实项目里。