為什麼Facebook的API以一個循環作為開頭？

作者 | Antony Garand

譯者 | 無明

如果你有在瀏覽器中查看過發給大公司 API 的請求，你可能會注意到，JSON 前面會有一些奇怪的 JavaScript：

為什麼他們會用這幾個位元組來讓 JSON 失效？

為了保護你的數據

如果沒有這些位元組，那麼有可能任何網站都可以訪問這些數據。

這個漏洞被稱為 JSON 劫持：

https://lmddgtfy.net/?q=JSON%20hijacking

也就是網站可以從這些 API 中提取 JSON 數據。

起 源

在 JavaScript 1.5 及更早版本中，可以覆蓋原始類型對象的構造函數，並使用括弧調用覆蓋的版本。

你可以這樣：

這樣就會彈出 alert！

使用以下腳本替換 var x，攻擊者就可以閱讀你的電子郵件！

這是通過在載入外部腳本之前覆蓋 Array 構造函數來實現的。

數據提取

即使你重載了構造函數，仍然可以通過 this 來訪問它。

這是一個代碼片段，它將 alert 數組的所有數據：

在創建數組後，它們的值將被 alert 出來！

ECMAScript 4 提案中已修復了這個問題，我們現在無法再覆蓋大多數原始類型的原型，例如 Object 和 Array。

儘管 ES4 從未發布，但主要瀏覽器在發現後很快就修復了這個漏洞。

在今天的 JavaScript 中，你仍然可以使用類似的行為，但它受限於你創建的變數，或者不使用括弧創建的對象。

這是之前的一個修訂版本：

這是一個使用 Array 關鍵字創建數組的版本：

如你所見，你添加到數組中的數據被記錄下來，但功能保持不變！

修復方案並沒有阻止使用 Array 來創建數組，而是在使用括弧創建對象時強制使用原生實現，而不是自定義函數。

這意味著我們仍然可以創建一個 Array 函數，但不能與方括弧（[1,2,3]）一起使用。

如果我們使用 x = new Array(1,2,3) 或 x = Array(1,2,3)，它仍將被調用，但不會給 JSON 劫持留下可趁之機。

新的變體

我們知道舊版本的瀏覽器很容易受到這個漏洞的攻擊，那麼現在呢？

隨著最近 EcmaScript 6 的發布，添加了很多新功能，例如 Proxies！

來自 Portswigger 的 Gareth Heyes 在博客（https://portswigger.net/blog/json-hijacking-for-the-modern-web）上介紹了這個漏洞的新變體，它仍然允許我們從 JSON 端點竊取數據！

通過使用 Proxies（而不是 Accessor），我們可以竊取到任意創建的變數，無論它的名稱是什麼。

它可以像 Accessor 一樣，但可以訪問任意可訪問或寫入屬性。

使用這個和另外一個技巧，就可以再次竊取數據！

UTF-16BE 是一個多位元組字符集，一個字元由兩個位元組組成。例如，如果你的腳本以 [「作為開頭，它將被視為字元 0x5b22 而不是 0x5b 0x22。0x5b22 恰好是一個有效的 JavaScript 變數 =)。

使用這個腳本：

通過使用這個腳本中的一些受控數據和移位腳本，我們就可以再次滲透數據！

這是 Gareth 最後的 POC，摘自他的博文：

我不會深入解釋這個方法，而是建議你閱讀他的帖子，以獲取更多信息。

預 防

以下是 OWASP 的官方建議：

https://www.owasp.org/index.php/AJAX_Security_Cheat_Sheet#Always_return_JSON_with_an_Object_on_the_outside

使用 CSRF 保護，如果不存在安全標頭或 csrf 令牌，就不返回數據，以防止被利用。

始終將 JSON 作為對象返回。

最後的解決方案很有趣。

在 Firefox 和 IE 中，這個是有效的：

但這樣不行：

它之所以無效是因為 Firefox 和 IE 認為括弧是塊語句的開頭，而不是創建對象。

沒有引號的符號被視為標籤，值被視為一個語句。

結 論

雖然這些東西在今天可能是無效的，但我們永遠不會知道明天將會帶來什麼新的錯誤，因此我們仍應儘力阻止 API 被利用。

如果我們把這個 StackOverflow 答案視為理所當然，我們就很容易受到現代變體的影響，因此仍然可能被黑客入侵：

https://stackoverflow.com/questions/16289894/is-json-hijacking-still-an-issue-in-modern-browsers

谷歌和 Facebook 在 JSON 數據之前添加無效的 JavaScript 或無限循環，OWASP 也列出了其他替代方案。

英文原文

https://dev.to/antogarand/why-facebooks-api-starts-with-a-for-loop-1eob

本文彩蛋

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！