如果你已经玩过一阵子OverTheWire的Bandit，一定会记得那种“在命令行里摸黑前进”的刺激感；而一旦切到Natas，画风立刻变成浏览器、HTML源码、HTTP请求头这些Web层面的东西。Natas是OverTheWire系列里专门练Web服务端安全的关卡，前五关（natas0到natas5）可以说是整套游戏里最友好的序章：不要求会写脚本，不要求懂加密，只要你会“看页面背后藏了什么”，就能一路过关。这篇文章是我从第0关打到第5关的完整记录，包括每一关的解题路径、底层原理和我实际踩过的小坑，给正准备入坑或者卡在某关的朋友做个参考。
1. 先别急着打：Natas在OverTheWire里是什么定位，适合什么样的人
1.1 它和Bandit那种“命令行爬楼”完全是两码事
OverTheWire是一系列安全挑战游戏的总称，每个子游戏侧重点都不一样。Bandit练的是Linux基础操作和权限概念，你基本上一直在SSH登录、敲命令、找文件、切换身份；Natas则直接转向Web安全，玩的是浏览器发出去的每一次请求，服务器可能因为哪些“想当然”而漏出信息。
Natas的每一关都是一个网页，用natasX作为用户名登录，页面或源码里藏着下一关的密码。这个设计带来一个好处：反馈非常直接。你不需要像打CTF那样从一大坨流量包里猜入口，也不需要理解复杂的题目背景，目标永远只有一个——在当前页面找到进入下一关的那串字符串。
1.2 零基础可以玩，但有一点基础会收获更大
如果你刚学完HTML和前端基础，知道<div>、<img>、注释是什么，Natas 0到5基本是零门槛的。它不会考你算法，不要求你装一堆工具，甚至一开始连Burp都用不上。
但我也要提醒一句：完全没有Web基础就直接玩，很容易把“过关”误当成“学会”。比如你按Ctrl+U看了一眼源码找到密码，如果不知道为什么密码会出现在那里、注释头是什么机制、robots.txt是什么东西，那打完五关也留不下什么。所以我建议，至少先知道浏览器是怎么把网页内容拉下来的、HTTP是什么、HTML注释长什么样，再来打这些小关卡，收获会完全不同。
2. 开打之前要搞懂的事：账号规则、工具选型与一条最重要的心法
2.1 密码链玩法：每一关的密码都是下一关的门票
Natas的账号体系有点像一个递进式的“钥匙链”。第0关的用户名是natas0，初始密码也是natas0，直接访问地址就能进。闯过之后，页面或源码里会出现客户端natas1的密码，一个32位的十六进制字符串。接下来要做的事情就变成：用natas1作为用户名、用刚拿到的字符串作为密码，登录natas1.natas.labs.overthewire.org这个地址。
这种设计看起来简单，但背后是HTTP Basic认证：浏览器每次请求都会自动带上Authorization头，把用户名和密码做一次编码后发给服务器。了解这一点，后面你用curl手动构造请求时会非常自然——你其实就是在手动扮演浏览器的角色。
2.2 工具清单与选择逻辑
我用到的工具比你想象中少得多，前五关其实只需要三类东西：
| 工具 | 用途 | 什么时候用 |
|---|---|---|
| 现代浏览器的开发者工具 | 查看源码、调试、看Cookie和Network请求 | 每一关都会用到 |
| curl（命令行） | 快速请求页面源码、手动加请求头和Cookie | 遇到浏览器不方便改包头时 |
| 抓包代理工具（社区版即可） | 拦截请求、修改Referer/Cookie、重放请求 | Level 4之后开始有需求 |
有些关卡的提示和源码在Windows的cmd里直接看会乱码，我建议直接用浏览器开发者工具看源码。curl更多是用来“验证思路”的，比如你已经知道要修改Referer头，但不想开重型代理工具，一条curl命令就解决了。
2.3 “看源码”为什么不是作弊
第一次接触Natas的人很容易有一个心理障碍：觉得“查看网页源代码”是某种偷看答案的行为。这里得把观念掰过来——Web应用本身就是把源码发送给浏览器的，浏览器拿到的HTML、CSS、JavaScript就是页面源码本身。服务器不可能在不给浏览器源码的情况下让页面正常显示，所以“看源码”不是漏洞利用技巧，而是Web开发与安全测试里最基本的信息收集动作。
Natas前五关几乎都在反复训练这件事：页面上的文字可能骗人，但HTML注释、标签属性、文件路径、隐藏字段不会无缘无故存在。养成“看到什么都要点开源码看一眼”的习惯，比记住任何攻击工具都重要。
3. Level 0 / Level 1：把“看源码”这个基本功练到滚瓜烂熟
3.1 Level 0 通关实录：第一个密码就藏在HTML注释里
第0关基本上是给你热身的。用natas0和natas0登录之后，页面就一句话：你可以在这页面上找到进入下一关的密码。我习惯性地按了Ctrl+U打开源码，往下扫了几行，就看到了关键注释：
<!-- The password for natas1 is 32位十六进制字符串 -->这关是真的送，但它帮助我确认了一个细节：注释是开发人员最常留信息的地方，也是信息泄露的高发区。很多真实网站里，程序员会在HTML注释里写“这里待会要接数据库”“请传参数id=xxx”，甚至直接留下内网地址。Natas第一关想教的不是“注释里有密码”，而是“把注释当成第一手情报来源”。
3.2 Level 1 通关实录：右键被禁之后还有三扇门
第1关的页面明显不一样了，正文写着：密码就在这一页，但右键已经被禁用。我试了一下，确实整个页面右键弹不出菜单，像是用oncontextmenu="return false"这类脚本把右键菜单屏蔽了。
这里有个常识：前端禁用右键能拦住普通用户，却拦不住任何想做调查的人。我试了三种方式，全部成功：
- 按
Ctrl+U直接查看原始页面源码； - 在地址栏输入
view-source:加URL； - 按
F12打开开发者工具，在Elements面板里看DOM。
密码就写在页面正文区域，源码里一眼就能看到。这关的核心不是“绕过右键”，而是帮你建立一个认知：浏览器二进制的责任是渲染页面，而开发者工具的存在就是为了让你观察一切细节。前端脚本永远不应该作为安全边界，因为客户端只是不可控的执行环境。
3.3 两关交叉点：Ctrl+U和F12不一样，为什么
很多新手在这里会困惑：Ctrl+U看到的源码和F12的Elements面板好像是一回事？其实有本质区别。Ctrl+U展示的是服务器最初返回的原始HTML文件，浏览器还没有做任何“修正”；而Elements面板里显示的是浏览器解析、渲染之后的DOM树，可能已经经过了JavaScript的增删改，也可能被浏览器自动补全了标签。
前两关用Ctrl+U就足够了，但到了后面的关卡，如果页面是通过JavaScript动态生成内容的，你就必须借助F12的Elements和Network面板去看“渲染后”的真实状态。可以把这个区别记住：原始源码是静态线索，动态DOM是运行时真相。
4. Level 2 / Level 3：顺着“目录”和“机器人文件”挖信息泄露
4.1 Level 2 通关实录：一张1像素图片指向可浏览目录
第2关打开页面只有一句话：这里什么都没发生，四处看看吧。页面文字确实没什么信息，我按惯例Ctrl+U，发现源码里有一行不起眼的标签：
<img src="files/pixel.png" width="1" height="1" />一个1像素的透明图片被引用了，路径是files/pixel.png。这个信息非常关键——它告诉我们，服务器根目录下存在一个叫files的文件夹。接下来的思路很自然：访问/files/本身，看看这个目录能不能被列举。
一试就中。浏览器直接列出了目录下的所有文件，里面除了一张像素图，还有一个users.txt。点开之后是natas3用户和它的密码。到这一步我才意识到，这关考的是“目录浏览漏洞”：当服务器没有关闭目录索引，且目录里没有默认首页文件时，访问目录会把整个文件列表吐出来。
4.2 Level 3 通关实录：robots.txt是一只暴露地图的“老鼠”
第3关页面上写着“没有更多信息泄露了，这次连搜索引擎都找不到它”。看到“搜索引擎”这个词，我的第一反应就是robots.txt。这个文件放在网站根目录，是给搜索引擎爬虫看的：哪些路径允许抓取，哪些路径禁止抓取。
访问/robots.txt后看到：
User-agent: * Disallow: /s3cr3t/这几乎是明牌了：搜索引擎不被允许进入/s3cr3t/这个目录，但robots.txt本身是公开的，任何人都能读。直接访问这个目录，又看到目录列表，里面依旧躺着一个users.txt，拿到natas4的密码。
有意思的是，这关的反讽之处在于：开发者以为把路径写进robots.txt就等于做了防护，实际上robots.txt更像是在墙上贴了一张地图，告诉所有路过的人“秘密在这边”。它不是访问控制机制，只是一份君子协定，真正的敏感资源永远不该靠“不告诉别人路径”来保护。
4.3 两关背后的共同套路：所有可见路径都值得继续挖
从第2关和第3关可以看出，Natas在教你一个思路：页面上的每一个URL、每一个路径、每一个文件引用，都可能是一扇没上锁的门。从pixel.png猜到files/目录，从robots.txt猜到s3cr3t/路径，这都是“顺着路径往里挖”的手法。
放在真实场景里，我见过不少网站把后台地址、备份压缩包、数据库导出文件直接放在用robots.txt声明的路径下，或者允许目录列表浏览，导致整站文件被下载。应对方案其实也很简单：关闭不必要的目录索引，敏感文件放到Web根目录之外，敏感路由不要出现在任何公开文件中，必要时刻用严谨的访问控制兜底。
5. Level 4 / Level 5：看清Referer与Cookie的信任边界
5.1 Level 4 通关实录：伪造“来路”过检查
第4关登录后，页面直接拒绝访问，并给出了一段很直白的话：
Access disallowed. You are visiting from "" while authorized users should come only from "http://natas5.natas.labs.overthewire.org/"这句话把答案写在脸上了：服务器检查的是HTTP请求头里的Referer字段，而且期望的“来路”就是natas5.natas.labs.overthewire.org。Referer头是浏览器在跳转页面时自动带上的，用于告诉服务器“我是从哪个页面来的”。问题在于它完全可以被人为修改。
我用curl做了一次验证，手动指定Referer头：
curl -u natas4:<上一关获得的密码> \ --referer "http://natas5.natas.labs.overthewire.org/" \ http://natas4.natas.labs.overthewire.org/返回内容直接变成了“Access granted”，下一关密码就在页面里。这关给我的触动特别大：开发者常常把“你从哪里来”当成“你是谁”的依据，但这两个概念根本不等价。Referer只是浏览器主动附带的参考信息，任何客户端都可以改成任意值。这就好比一个人进门时报了个假名字，而门卫只根据假名字就放行了。
5.2 Level 5 通关实录：把loggedin=0改成1
第5关的页面同样是拒绝访问，提示“你没有登录”。但有意思的是，我打开开发者工具的Application面板，发现Cookie里躺着一个叫loggedin的字段，值是0。
这个字段是什么意思已经不需要猜了：服务端大概是用Cookie里的loggedin标记来判断用户是否登录。我把值双击改成1，刷新页面，直接看到了下一关的密码。
Cookie机制本身是中性的：服务端通过Set-Cookie头把一段数据发给浏览器，浏览器在后续请求中再把这段数据原样带回去。问题出在服务端单方面信任了客户端传来的Cookie值。一个反例是“会话状态应该由服务端保存，客户端只保存一个随机的会话ID”。如果直接把是否登录这种核心状态放进一个没有签名的Cookie里，那等于把身份判断权交给了每一个访问者。
5.3 修改请求头和Cookie的三种实操姿势
Natas第4、5关都需要修改请求级数据，我试过三种方式，各有利弊：
| 方式 | 操作要点 | 适合场景 |
|---|---|---|
| 开发者工具直接改Cookie | Application面板双击Cookie值 | 只想改登录状态这类简单值 |
| 浏览器请求头插件 | 设置Referer为固定值后刷新页面 | 不想开代理，快速改单个头 |
| 抓包代理工具 | 拦截请求、修改后放行 | 后面关卡需要组合改多个参数时 |
| curl命令行 | 用--referer和--cookie指定 | 验证思路最快，适合复现 |
我个人最喜欢curl的方式，它能把整个思考过程固化成一个命令，方便记录下来反复观察。改Cookie的版本也很简单：
curl -u natas5:<上一关获得的密码> \ --cookie "loggedin=1" \ http://natas5.natas.labs.overthewire.org/5.4 两个“客户端信任”漏洞的防御思路
Level 4和Level 5本质上是同一个安全误区：把客户端可控数据当作信任依据。防御思路并不复杂。Referer头不该用于鉴权，如果真的需要校验来源，应该使用带随机性的CSRF Token，或者至少结合Origin头做辅助判断；Cookie中的登录状态必须使用服务端会话机制，Cookie本身只保存不可预测的Session ID，并且加上HttpOnly、Secure、SameSite等属性，防止脚本读取和跨站发送。
真实环境里的漏洞往往比这两关更隐蔽，可能是一个role=user的字段、一个isAdmin=true的隐藏input，或是一个可以任意修改的加密数据块。但解题思路是一模一样的：看到客户端能控制的数据，就直接怀疑服务端是否对它有过多信任。
6. 通关复盘：这五关究竟练了什么，接下来往哪走
6.1 一张表看懂0到5关的考察点
把前五关拉通看，其实每一关都对应一个非常具体的信息泄露或信任校验问题：
| 关卡 | 核心考察点 | 关键线索 | 现实对应问题 |
|---|---|---|---|
| Level 0 | 查看源码 | HTML注释 | 敏感信息直接写在前端代码里 |
| Level 1 | 绕过右键禁用 | 开发者工具快捷键 | 前端限制不等于安全控制 |
| Level 2 | 目录浏览 | img标签指向files路径 | 目录索引泄露文件列表 |
| Level 3 | robots.txt | “搜索引擎也找不到”提示 | 机器人协议暴露敏感目录 |
| Level 4 | 伪造Referer | 页面直接给出期望来路 | 把来源地址当身份凭证 |
| Level 5 | 篡改Cookie | loggedin=0状态标记 | 客户端可控的登录状态 |
这些点单看都很基础，但正好是Web安全里出现频率最高的一批问题。Natas把它们铺成一条递进路线，就是想让新手从最表层的信息泄露，一步步走向更核心的“服务端与客户端信任关系”问题。
6.2 继续往后打，会新出现哪些方向
过了Level 5，Natas会明显增加难度。从第6关开始，你已经不能只靠“看源码+改参数”过关了，会碰到文件包含漏洞、需要猜解参数、构造注入语句、审计加密逻辑等更接近真实渗透场景的技巧。很多关卡还会要求你写简单的脚本去爆破、循环请求或者处理加密流程。
但是你会发现，不管后面的关卡多复杂，思路和第0到第5关是连贯的：先收集一切可见信息，再找出服务端可能误信的点，最后构造一个特殊请求验证猜想。前五关建立的信息收集习惯和“别信表面”的心态，才是它们真正的价值所在。
6.3 我打完后留下的三个习惯
打完这五关，我给自己总结了几条可以复用一辈子的操作习惯。
第一，访问任何网站，第一件事永远是Ctrl+U看源码，重点扫注释、脚本引用、表单隐藏字段，这一步能发现大量意外信息。
第二，看到任何一个路径，都习惯性去掉文件名试试访问上级目录。比如看到/img/pixel.png，就顺手访问一下/img/，很多备份文件就是这么被翻出来的。
第三，登录任何Web应用时，打开开发者工具的Application面板看一眼Cookie。如果发现role、loggedin、isAdmin这类状态字段可以轻易修改，就要意识到服务端可能存在信任问题。
我记得自己在Level 5改完Cookie拿到密码后，特意回头把第0关重新打了一遍。第二次的速度快了很多，但收获反而更大——第一次我只是跟着提示找答案，第二次才真正看明白，每一关都在锻炼同一个思维：把网站当成一组可观测、可伪造、可往深处挖的数据包，而不是一个无从下手的黑盒。后面关卡会越来越难，但只要你在这五关里养成了“什么都想看源代码”的习惯，它们就会变成你继续往下走的底气。
