关注这个靶场的其他相关笔记：XSS - LABS —— 靶场笔记合集-CSDN博客
0x01：过关流程
进入关卡，右击页面，查看页面源代码，搜索 good job!，查看回显点（这里埋下一个坑）：
通过查看源码，我们发现了页面又存在隐藏表单的行为，这里就不再像上一关那样麻烦的，又是让标签显示，又是自己编写提交按钮了，我们根据 name 中的内容，直接构造 GET 请求，查看页面的回显点：
?t_link=test1&t_history=test2&t_sort=test3&t_ref=test4
可以发现回显点又是 t_sort，那么下面我们针对该回显点测试后端过滤规则：
| Payload | Echo Print |
|---|---|
" | " |
' | ' |
< | < |
> | > |
script | script |
on | on |
至此，我们又一次的陷入了死局，无法逃逸出双引号，也没办法创建新的标签。
经过笔者开过天眼后，发现，从本关开始，似乎已经开始将注意力转向了究竟是哪个参数能够触发 XSS 的问题，而不像前 10 关主要都是集中在如何绕过过滤。
在 Level 11 中，之前有个字段一直被我们忽略，就是 t_ref，我们在测试过，对其传参并不会回显后就直接放弃了对其的测试。然而，本关的突破口就在这，该参数回显的并不是我们通过 GET 传递的数据，而是请求包的 Referer 字段（这能联想？作者这猪脑是联想过了，但是没测试过，不愧是 CTF）：
知识拓展：HTTP Referer
HTTP Referer 是 HTTP 请求头的一部分，Referer 字段包含了发起请求的前一个 URL 地址，即用户访问当前页面之前所在的页面地址。当用户通过点击一个链接从一个网页导航到另一个网页时，浏览器会在新的 HTTP 请求中包含 Referer 字段，其值为用户点击链接前所处的页面的 URL。如果用户直接在地址栏输入 URL 或者通过书签、刷新页面等方式访问一个页面，那么 Referer 字段通常不会被发送，或者设置为 null。
修改请求包的 Referer 字段，我们既可以使用 BurpSuite 进行抓包修改，还可以便捷一点，使用浏览器插件 HackBar，HackBar 的详细教程链接如下：
https://blog.csdn.net/m0_73360524/article/details/141298896进入关卡，鼠标右击页面，点击检查，选中 HackBar 插件，点击 Load URL，载入当前网址，并勾选 Referer 字段：
我在新添加的 Referer 字段中填写了 123456，并点击 Execute，准备测试一下目标的回显状态：
由上面的图片可知，我们成功找到了注入点，下面就是绕过引号过滤，并且为 input 标签添加事件监听，所以 Payload 如下（同样输入在 HackBar 的 Reference 字段中）：
" type="text" onmouseover="alert(1)
0x02：源码分析
下面是 XSS LABS Level 11 的源码，以及我对其的部分笔记：
<!DOCTYPE html><!--STATUS OK-->
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<script>
// 修改 alert 的默认行为，跳转进入下一关
window.alert = function() {
confirm("完成的不错！");
window.location.href = "level12.php?keyword=good job!";
}
</script>
<title>欢迎来到level11</title>
</head>
<body>
<h1 align=center>欢迎来到level11</h1>
<?php
ini_set("display_errors", 0);
$str = $_GET["keyword"]; // 接收 GET 传参 keyword
$str00 = $_GET["t_sort"]; // 接收 GET 传参 t_sort
$str11 = $_SERVER['HTTP_REFERER']; // 接收 HTTP 请求包中的 Referer 来源字段
$str22 = str_replace(">", "", $str11);
$str33 = str_replace("<", "", $str22);
echo "<h2 align=center>没有找到和" . htmlspecialchars($str) . "相关的结果.</h2>" . '<center>
<form id=search>
<input name="t_link" value="' . '" type="hidden">
<input name="t_history" value="' . '" type="hidden">
<input name="t_sort" value="' . htmlspecialchars($str00) . '" type="hidden">
<input name="t_ref" value="' . $str33 . '" type="hidden">
</form>
</center>'; // $str33 只是过滤了参数中的 <>，并不严格，可以通过 " 逃逸出去，导致 XSS 漏洞
?>
<center><img src=level11.png></center>
<?php
echo "<h3 align=center>payload的长度:" . strlen($str) . "</h3>";
?>
</body>
</html>通过对后端代码的分析，感觉似乎是遇到了一个瓶颈，是不是，只要一个参数使用了 htmlspecialchars() 且其被包裹在"内或者不被任何标签包裹，就并无绕过的可能了（像能直接触发javascript:alert(1) 这种不考虑在内）？回想靶场的前几关，我们只在 Level 3 中成功绕过了 htmlspecialchars()，原因是回显点在'内，而 PHP 低版本中的 htmlspecialchars() 并不会对 ' 号进行 HTML 编码，导致我们成功逃逸，但这个 Bug 在 PHP 8 中已经没了（PHP 8 的 htmlspecialchars() 默认是会对其进行编码的）。
<!-- 思考：下面的代码是否存在绕过的方案，在 PHP 5 中（放低要求）？ -->
<meta charset="utf-8">
<?php
$keyword = htmlspecialchars($_GET["keyword"]);
// Kind 1：经过 htmlspecialchars 过滤后，直接显示在标签内
echo "<div> 您传递的内容为：" . $keyword . "</div><br>";
// Kind 2：经过 htmlspecialchars 过滤后，显示在不能触发 javascript:alert(1) 的标签内，且标签被 " 号包裹
echo '<input type="text" value="' . $keyword . '">';
?>0x03：靶场复盘
0x0301：为什么进入关卡后 t_ref 的 value 字段为空？
经过源码分析后，我们发现 t_ref 字段的取值是来自请求头中的 Referer 字段，那么为什么，在过关流程第一步中，我们查看源码时，发现 t_ref 的 value 字段值为空呢（按照常理，我们从 Level 10 跳转到 Level 11 时，请求头中肯定会有 Referer 字段，且值为 Level 10 的过关 URL）？
经过复盘，笔者发现是，可能是笔者一边记笔记，一边过关的缘故，在进入 Level 11 的时候通过地址栏输入 URL 的方式直接访问关卡，导致浏览器没有发送 Referer 字段，进而造成了 Bug：
下面笔者通过询问 AI，总结了几条浏览器不发送 Referer 字段的场景（并未测试，但是感觉挺有意思的）：
-
直接访问： 如果用户直接在浏览器的地址栏中输入 URL，或者通过书签访问页面，那么这次请求通常不会包含
Referer字段，因为没有 “来源” 页面。 -
隐私模式或安全设置： 某些浏览器在隐私模式（无痕模式）下或当用户启用了特定的安全设置时，可能会阻止发送
Referer字段。 -
HTTPS 到 HTTP 的降级： 如果用户从一个 HTTPS 页面导航到一个 HTTP 页面，出于安全的考虑，某些浏览器可能不会发送
Referer字段，以防止敏感信息泄露。 -
重定向： 如果请求经过了重定向（比如从 HTTP 重定向到 HTTPS），那么原始的
Referer字段可能会被清除或修改。 -
浏览器插件或扩展： 安装的浏览器插件或扩展可能会修改或删除 HTTP 请求的头部信息，包括
Referer字段。 -
浏览器缓存： 在某些情况下，浏览器缓存可能会导致请求看起来没有包含
Referer字段，但实际上可能是存缓存中加载的内容而不是新的请求。
思维拓展：利用 Referer 攻击？
这里纯属笔者记着记着瞎想的，分享出来，给大家拓宽一下思维。
攻击思路：
Referer 字段的值是上一个请求来源的 URL，而有些网站又会将敏感信息通过 URL 传递。攻击者是否就可以通过 Referer 字段，读取那些敏感信息。
场景假设：
A 网站，被攻击方，喜欢将敏感信息放在 URL 上，还喜欢贴广告赚钱。
B 网站，Hacker 搭建的网站，会记录请求的 Referer 信息。
攻击流程：
客户小红，在 A 网站的管理后台上操作时，不小心点击到了广告链接，此广告会直接跳转到 B 网站（携带 Referer 字段），Hacker 通过查看后台获取的 Referer 字段，成功冒充小红的身份，进入 A 网站。
0x0302：此种类型的 XSS 漏洞如何利用？
本次关卡的 XSS 漏洞点是在 HTTP 请求头的 Referer 字段中。而 Referer 字段是浏览器自行添加的，无法直接通过注入 javascript 代码来进行操作。那么，这种类型的 XSS 漏洞应该如何利用呢？
没有利用价值的漏洞，等于没用。我们不可能期待攻击者自己去修改 Referer 字段，自己攻击自己吧。下面笔者在这里提供几个攻击思路：
1. 编写浏览器插件并发布
如上，我们攻击使用的是 HackBar 插件，它就可以修改请求的 Referer 字段。证明了插件修改请求字段的可行性。
那攻击者是否可以也编写一个插件，内部隐藏攻击代码，如果受害者电脑上安装了此插件，并且访问了指定站点（含有 XSS 漏洞的站点），插件自动触发攻击，重新请求该页面，并修改 Referer 字段，导致页面被篡改。
这个纯属作者臆想，不过作者感觉有搞头。
2. 利用重定向攻击（失败了）
XSS 漏洞点在 Referer 字段利用还是有点难度的，下面是笔者根据臆想写的一个利用站点，但是利用失败了，分享出来，让你们笑一下：
<!-- attacker.php -->
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>XSS Level 11 利用站点</title>
</head>
<body>
<a href='?redirect=true&payload=" type="text" onmouseover="alert(1)'> 这是一个人畜无害的超链接 </a>
<?php
$redirect_sign = $_GET["redirect"];
if ($redirect_sign == "true") {
// 如果存在重定向标志，则重定向到存在漏洞的站点
echo '<script>window.location.href = "http://127.0.0.1/xss-labs/level11.php?keyword=good%20job!";</script>';
}
?>
</body>
</html>下面是笔者臆想的攻击流程：
下面是来自现实的打脸，Referer 字段是浏览器自动添加的，而且还会对特殊符号进行 URL 编码：
至于 PHP 脚本中用来跳转的语句，为什么要通过输出一个 javascript 脚本来完成，给你们看个图就知道了，下面是我通过 header 跳转后的样子（因为用 header 差点吓得我把之前笔记删了）：
问题就出在这，通过 header() 进行重定向，上一个页面的参数并不会被携带，既然不会被携带，还攻击个啥哦。
扫一扫
1288
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
