?? 一段簡單的 JSON 解析代碼，可能是一次嚴(yán)重的原型污染、提權(quán)繞過、服務(wù)癱瘓的開始。本文深入解析 JSON.parse() 的安全風(fēng)險、攻擊方式，并講解如何在黑盒測試中通過數(shù)據(jù)包行為反推出后臺邏輯，為你打開攻防對抗中的新視角。
?? 1. JSON.parse 是什么？它本身安全嗎？
JSON.parse() 是 JavaScript 原生函數(shù)，用于將字符串解析為 JavaScript 對象：
const obj = JSON.parse('{"user":"admin"}');
? 它本身不會執(zhí)行代碼、不會像 Java 反序列化一樣觸發(fā)遠(yuǎn)程類加載或代碼執(zhí)行。
??但它存在安全隱患的傳播點，關(guān)鍵在于：你如何使用解析后的對象！
?? 2. 典型安全風(fēng)險與利用場景
? 風(fēng)險一：原型鏈污染（Prototype Pollution）
關(guān)鍵字段如 __proto__ / constructor / prototype 被寫入對象中，通過合并操作傳播到所有對象。
?? 利用前提：
- 后端用
Object.assign、lodash.merge 等合并用戶傳參與默認(rèn)配置。
?? 典型 payload：
{
"__proto__": {
"admin": true
}
}
?? 后果示例：
const config = Object.assign({}, defaultConfig, JSON.parse(userInput));
// 之后任何 new Object() 都可能帶上 admin: true
?? 常見數(shù)據(jù)包格式
POST /api/profile HTTP/1.1
Host: target.example.com
Content-Type: application/json
Content-Length: 70
{
"__proto__": {
"isAdmin": true
}
}
? Burp 分析方法：
| 步驟 | 觀察點 |
|---|
| 1. 請求發(fā)出 | 目標(biāo)接口是否處理 JSON 格式數(shù)據(jù) |
| 2. 重復(fù)訪問其他接口 | 是否行為改變（權(quán)限 / 響應(yīng)內(nèi)容） |
| 3. Proxy + Repeater | 逐步調(diào)整 payload，如 ["__proto__"] |
| 4. 添加測試斷點 | 使用 Logger++ 插件記錄響應(yīng)中的 isAdmin 等字段是否被反映 |
如果行為生效，將獲得Admin權(quán)限，頁面菜單等權(quán)限將有明顯改變
? 風(fēng)險二：拒絕服務(wù)攻擊（Billion Laughs / Deep Nesting DoS）
{
"a":{"a":{"a":{"a":{"a":{"a":{"a":{"a":{"a":{"a":{}}}}}}}}}}
}
- 重復(fù)嵌套結(jié)構(gòu)觸發(fā) CPU 暴漲或內(nèi)存崩潰。
? 風(fēng)險三：DOM-Based XSS（前端使用不當(dāng)）
如果前端用 innerHTML 或 document.write 直接渲染 JSON 解析的字段：
const data = JSON.parse(payload);
document.body.innerHTML = data.content;
攻擊者構(gòu)造：
{"content": "<img src=x onerror=alert(1)>"}
?? 3. 數(shù)據(jù)包特征分析
我們?nèi)绾?*在黑盒測試中識別系統(tǒng)內(nèi)部使用了 JSON.parse()**？以下是典型思路：
?? 特征：API 接收 JSON 格式 body
POST /api/config HTTP/1.1
Content-Type: application/json
{"username":"admin"}
?? 判斷方式分析：
| |
|---|
| 是 → 可能直接 JSON.parse 解析并用于配置邏輯 |
修改特殊鍵如 __proto__ 有無響應(yīng)變化？ | |
| 是否響應(yīng)體中出現(xiàn)原樣字段回顯？ | |
| 是否異常響應(yīng)（500 / timeout）？ | |
??? 組合測試
- 提交
constructor.prototype.polluted = true → 檢查全局污染跡象 - 利用
["__proto__"] 數(shù)組索引寫入，繞過某些黑名單
?? 4. 防御建議
| |
|---|
| 禁止解析中出現(xiàn) __proto__、constructor 等關(guān)鍵字段 |
| 避免使用 Object.assign，推薦 structuredClone() 或安全庫 |
| 使用庫如 json-parse-better-errors、ajv 等做層級與結(jié)構(gòu)校驗 |
| 對 JSON payload 關(guān)鍵字（如 "__proto__"）做識別和阻斷 |
| 后端合并配置時應(yīng)隔離用戶與系統(tǒng)配置空間，避免全局污染 |
? 總結(jié)
| |
|---|
| JSON.parse本身安全 |
| 使用方式不安全：合并配置、渲染 HTML、未校驗字段 |
| |
| 利用字段污染 → 影響權(quán)限邏輯 / 全局變量 / DoS |
| 嚴(yán)格輸入控制 + 合理合并方式 + 安全庫使用
|
閱讀原文：原文鏈接
該文章在 2025/4/24 9:23:14 編輯過
400 186 1886
