怎样快速发现HTML页面中的反序列化关联漏洞-html教程-PHP中文网

json.parse()处理用户可控输入存在风险，若后续结合eval、innerhtml等操作会触发xss或代码执行；需检查location.hash、localstorage等数据源及eval、function构造器等危险模式。

怎样快速发现html页面中的反序列化关联漏洞

直接看页面是否在用 JSON.parse() 处理用户可控输入

反序列化漏洞在 HTML 页面里不叫“反序列化”，而是表现为 JSON.parse() 被误用于不可信数据源。只要看到它解析来自 location.search、location.hash、localStorage 或 fetch() 响应体的内容，就存在风险前提——虽然 JS 的 JSON.parse() 本身不会执行代码，但若后续把解析结果喂给 eval()、setTimeout()、innerHTML 或基于属性名动态调用函数（如 obj[ userInput ]()），就构成实际可利用链。

常见错误模式：

JSON.parse(decodeURIComponent(location.hash.slice(1))) 后直接赋值给 obj.callback 并调用
从 API 拿到 JSON 数据后，用 Object.keys(data).forEach(key => element.innerHTML += `<div>${data[key]}</div>`) —— 若 data 是服务端未过滤的原始响应，且字段含恶意 HTML，就滑向 XSS；若再结合模板拼接或 with()，可能触发更深层逻辑漏洞
富文本编辑器导出的 JSON 配置被前端 JSON.parse() 后，递归渲染时未校验 key 名（如 onerror、onclick）

检查是否有手动反序列化逻辑绕过 JSON 安全边界

真正的危险点常藏在“非标准反序列化”里：比如用 eval('(' + jsonStr + ')') 替代 JSON.parse()，或用 Function 构造器动态执行 JSON 字段值。这类写法会完全绕过 JSON 语法限制，允许执行任意 JS 表达式。

搜索关键词（在 DevTools 的 Sources 面板全局搜索）：

eval(.*?\{ 或 eval\(.*?location
new Function$.*?$
atob$.*?$ + 后续 eval（常见于混淆传输的 payload）
innerHTML =.*?\+.*?\} 类字符串拼接（尤其拼接的是未清洗的 JSON 字段）

注意：现代框架（React/Vue）默认不暴露此类接口，但手写管理后台、旧版配置页、埋点 SDK 初始化代码里仍高频出现。

识别服务端返回 JSON 中是否携带攻击面字段

很多 HTML 页面的“反序列化风险”其实源头在后端。例如：页面初始化时请求 /api/config，返回的 JSON 包含

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

{"callback": "alert(1)", "template": "@@##@@，前端 JS 不加判断直接执行或插入，就等于把服务端的不安全反序列化后果带到了浏览器端。
<p>快速检测步骤：</p>

打开 DevTools → Network → 刷页面，筛选 XHR/Fetch 请求，逐个点开 Response 查看是否返回结构化 JSON
重点扫描字段名：包含 callback、<code>handler、render、template、content、html、js 等关键词的键值对
若值是字符串且疑似 JS 代码或 HTML 片段（含 <script></script>、javascript:、onerror=），记录该接口路径，提交给后端团队核查反序列化逻辑

这类问题不是前端能单方面修复的，但前端可加一层白名单校验（如只允许 callback 值为预设函数名数组中的项）。

别忽略 URL 参数被当 JSON 解析的隐蔽场景

有些页面会把整个 URL 参数当作 JSON 对象解析，比如 ?config=%7B%22theme%22%3A%22dark%22%7D → JSON.parse(decodeURIComponent(new URLSearchParams(window.location.search).get('config')))。此时攻击者可构造恶意 config 参数，注入带事件处理器的字符串或原型污染键（如 "__proto__"、"constructor"）。

验证方式：

在地址栏手动修改参数为 ?config={"x":"y"}，看页面是否正常；再试 ?config={"onerror":"alert(1)"}，观察控制台报错或 DOM 是否变化
若页面崩溃、报 SyntaxError，说明没做 try/catch，属于低级错误；若静默失败或部分生效，说明解析逻辑已嵌入业务流，风险更高
特别留意使用了 URLSearchParams + JSON.parse() 组合的代码段，这是近年新出现的高危模式

真正容易被忽略的是：这种解析往往不在主逻辑里，而藏在某个第三方统计 SDK 的初始化脚本中，或者埋点配置的异步加载回调里。