国产成人精品免费视频大全五级 ,亚洲精品综合网在线8050影院 ,成人久久18免费网站入口

最重要的是，官方 RFC 并不是唯一的規(guī)范。你還有ECMAScript、JSON5、HJSON，甚至二進(jìn)制 JSON (BSON )。

這可能讓人抓狂。解析器之間的互操作性暴露了許多人甚至沒有意識(shí)到的安全風(fēng)險(xiǎn)。

讓我給你舉幾個(gè)例子。

JSON 解析器互操作性中的安全問(wèn)題

JSON 解析器之間存在一些互操作性安全問(wèn)題。BishopFox 對(duì)該主題進(jìn)行了一些出色的研究，我在此總結(jié)一下。如果您對(duì)這些問(wèn)題感興趣，我強(qiáng)烈建議您查看他們關(guān)于該主題的研究。

處理重復(fù)密鑰的方式不一致

我希望你考慮一下這個(gè)例子：

fu = {“bar”: 1, “bar”: 2}

的值是否fu[“bar”]等于1或2？或者會(huì)產(chǎn)生錯(cuò)誤？

根據(jù)官方規(guī)范，任何結(jié)果都是完全可以接受的。如果你總是期望它以特定的方式工作，那就有問(wèn)題了。

因此，如果您有一個(gè)用 Python Flask 編寫的前端公開 API，它會(huì)使用最后一個(gè)鍵的優(yōu)先級(jí)，結(jié)果為 2。

但是，如果該有效負(fù)載被轉(zhuǎn)發(fā)到后端的單獨(dú)微服務(wù)進(jìn)行進(jìn)一步處理，情況會(huì)怎樣？假設(shè)它是用 Golang 編寫的。那么，它使用第一鍵優(yōu)先，結(jié)果為 1。

看到這里的問(wèn)題了嗎？

因此，您需要確保在依賴 JSON 對(duì)象的代碼中正確理解順序優(yōu)先級(jí)。否則，這可能會(huì)成為一種可能的攻擊媒介，您可以通過(guò)以特定順序使用重復(fù)鍵來(lái)操縱業(yè)務(wù)邏輯，使其以意想不到的方式工作。

這就是為什么在偵察過(guò)程中檢測(cè) API 組件的編程語(yǔ)言非常重要。您需要了解正在使用的語(yǔ)言，并嘗試找出 JSON 對(duì)象的解析方式。

按鍵碰撞響應(yīng)不一致

當(dāng)解析器以不一致的方式處理特殊字符或注釋時(shí)，就會(huì)發(fā)生鍵沖突。

例如，在 Python 2.x 中，JSON 解析器在處理某些 Unicode 的方式上有所不同。

考慮以下 JSON 塊：

{“bar”:1,”bar\ud888”:2}

默認(rèn) JSON 解析器會(huì)將其干凈地處理為兩個(gè)不同的鍵。但是，Python 中流行的 ujson 解析器會(huì)截?cái)?Unicode，將鍵視為重復(fù)項(xiàng)，并接受 Python 的最后一個(gè)鍵優(yōu)先級(jí)。結(jié)果如何？標(biāo)準(zhǔn) JSON 解析器將 bar 的值視為 1，而 uJSON 解析器將 bar 的值視為 2。

查看下面的屏幕截圖，了解實(shí)際操作的示例……

JSON 序列化（反序列化）中的不一致

雖然我們一直在討論鍵的優(yōu)先級(jí)，但我們實(shí)際上一直在展示反序列化過(guò)程中的問(wèn)題。事實(shí)上，這也可能發(fā)生在序列化過(guò)程中。

有時(shí)序列化和反序列化本身是不一致的。

以 Java 的 JSON 迭代器為例……

輸入：

fu = {“bar”: 1, “bar”: 2}

輸出：

fu[“bar”] // 1

fu.toString() // {“bar”: 2}

所以在同一個(gè)解析器中，鍵的檢索和序列化的值是不同的。底層數(shù)據(jù)結(jié)構(gòu)保留了重復(fù)鍵的值，但序列化器和反序列化器之間的優(yōu)先級(jí)不一致。

JSON RFC 不會(huì)阻止重復(fù)鍵的序列化。因此，您必須依賴于理解所有組件中數(shù)據(jù)序列化和反序列化過(guò)程中鍵的順序優(yōu)先順序。

舉個(gè)例子，C++ rapidjson 解析器會(huì)以不同的方式處理相同的數(shù)據(jù)：

輸入：

fu = {“bar”: 1, “bar”: 2}

輸出：

fu[“bar”] // 2

fu.toString() // {“bar”: 1, “bar”: 2}

如您所見，相同的 JSON 對(duì)象在解析時(shí)可能會(huì)得到不同的結(jié)果。重新序列化這些對(duì)象并不能提供任何保護(hù)，因?yàn)閿?shù)據(jù)可能會(huì)有所不同，從而使攻擊者能夠繞過(guò)清理邏輯偷偷獲取值。

這可能導(dǎo)致業(yè)務(wù)邏輯缺陷、注入漏洞或其他安全風(fēng)險(xiǎn)。

JSON 解析器很爛，我該如何利用它？

希望您能夠看到如何濫用 JSON 并注入可能導(dǎo)致應(yīng)用程序以開發(fā)人員未預(yù)料的方式運(yùn)行的數(shù)據(jù)。除了我之前提到的結(jié)構(gòu)化格式注入之外，當(dāng)您可以操縱數(shù)據(jù)如何在 API 基礎(chǔ)架構(gòu)內(nèi)遍歷組件時(shí)，您就可以開始控制邏輯流程。

例如，如果您知道 JSON 對(duì)象直接序列化到數(shù)據(jù)庫(kù)（例如 MongoDB、Couchbase、DynamoDB、CosmosDB 等）并反序列化到使用不同解析器的外部組件，那么就有機(jī)會(huì)污染數(shù)據(jù)并查看它如何進(jìn)出 API。

考慮一個(gè)類似這樣的 API 請(qǐng)求流程：輸入清理阻止創(chuàng)建管理員

POST /user/create HTTP/1.1 ... Content-Type: application/json { "user": "dana", "role": "administrator" } HTTP/1.1 401 Not Authorized ... Content-Type: application/json {"Error": "Assignment of internal role 'administrator' is forbidde

因此我們可以看到輸入驗(yàn)證不允許我們將角色設(shè)置為管理員。

了解解析器如何處理輸入允許您利用解析器的行為以您可以操縱的方式解釋數(shù)據(jù)，從而潛在地繞過(guò)輸入清理。

想想之前的 Python 示例。想象一下，如果您使用 Unicode 字符截?cái)鄮魟?chuàng)建對(duì)象中名為“ role ”的鍵中的值。突然間，“ administrator\ud888”被解析為“ administrator”，并且 API 內(nèi)的 privesc 成為可能。

最終看起來(lái)是這樣的：JSON 注入允許繞過(guò)清理以獲得管理員權(quán)限

POST /user/create HTTP/1.1 ... Content-Type: application/json { "user": "dana", "role": "administrator\ud888" } HTTP/1.1 200 OK ... Content-Type: application/json {"result": "OK: Created user ‘dana’ with the role of ‘a(chǎn)dministrator’"}

這就是 JSON 注入的最高境界，這要?dú)w功于奇特的 JSON 解析器。

結(jié)論

對(duì)三星智能中心的攻擊只是 JSON 注入如何導(dǎo)致一系列復(fù)雜的漏洞鏈（從 SQL 注入到遠(yuǎn)程代碼執(zhí)行）的一個(gè)例子。?

正如我們所見，根本原因通常在于 JSON 解析器處理數(shù)據(jù)的方式不一致，尤其是當(dāng)涉及具有不同怪癖的多個(gè)解析器時(shí)。這些漏洞凸顯了了解 JSON 在 API 基礎(chǔ)架構(gòu)中的不同語(yǔ)言和組件之間解析和處理方式的細(xì)微差別的重要性。

通過(guò)徹底審查 JSON 對(duì)象的序列化、反序列化和處理方式，您可以開始弄清楚如何制作可以繞過(guò)清理過(guò)濾器并影響業(yè)務(wù)邏輯的有效負(fù)載。

由于 API 繼續(xù)成為現(xiàn)代應(yīng)用程序的基石，因此確保其處理數(shù)據(jù)的安全性比以往任何時(shí)候都更加重要。希望我今天能讓您對(duì)此有所了解。

對(duì)各種內(nèi)容進(jìn)行注入嘗試。如果不親自動(dòng)手，你永遠(yuǎn)無(wú)法了解它們會(huì)被如何處理。

文章轉(zhuǎn)自：使用JSON注入攻擊API