我們有一個角度前端應用和asp.net核心web api後端的設置。 API使用json進行響應。 問題是,應該json屬性是否被html編碼?REST API - JSON內容應該是HtmlEncoded嗎?
我可以看到兩個原因:親和騙局。
另一方面,REST API應該是客戶端不可知論者(因此,不應該特別關心html),另一方面,僅依靠客戶端XSS預防感覺有點冒險。
想法?
我們有一個角度前端應用和asp.net核心web api後端的設置。 API使用json進行響應。 問題是,應該json屬性是否被html編碼?REST API - JSON內容應該是HtmlEncoded嗎?
我可以看到兩個原因:親和騙局。
另一方面,REST API應該是客戶端不可知論者(因此,不應該特別關心html),另一方面,僅依靠客戶端XSS預防感覺有點冒險。
想法?
的幾點:需要針對不同上下文
application/json
,否則如果json端點本身包含<script>
等,它將容易受到XSS的影響。<script> var data = "{'key1': 'val1', 'key2': 'val2'}"; </script>
這看起來不錯,但看看這個:
<script> var data = "{'key1': 'val1', 'key2': '</script><script>alert(1)</script>'}"; </script>
它看起來像一個簡單的字符串,但瀏覽器主要是一種HTML解析器。它找到< script>和</script>之間的內容,並將其作爲Javascript執行。字符串中的第一個</script>
碰巧與第一個<script>
標記配對,並且字符串中的第一個打開標記將啓動一個全新的腳本,從而導致XSS。
因此,如果您打算將JSON作爲Javascript的一部分寫入html(這是一種非常常見的用法),那麼您需要將JSON內容編碼爲HTML。避免這種情況並單獨下載數據會更好。
這些都是非常好的一點!感謝那! content-type總是application/json,當然,我也喜歡json的數據只是數據(如果非html客戶端使用api,這尤其有意義)。所以,如果我正確地讀了你,你更傾向於客戶決定天氣它應該htmlencode json的一些部分或不? –
是的,我認爲它不應該編碼除了編碼JSON本身的值,以使jaon結構完好無損。從那裏開始,數據消費者的工作就是處理任何進一步的編碼,例如。對xss的html或javascript編碼。做json值的html編碼的一個原因可能是如果你想將它寫入頁面來初始化一個js變量,但我認爲最好避免這種情況。 –
是的,我同意。我會將你的文章標記爲答案,讓我們澄清一個細節:通過'將json值寫入頁面來初始化js變量',你究竟意味着什麼?謝謝! –
嗯,不得不考慮它,但我會這樣做: 沒有額外的HTML編碼JSON的頂部。確保您設置了正確的內容類型。如果您有「不安全」的數據字段,那麼您認爲這些數據字段特別危險,那麼您可以在文檔中將其指定爲HTML編碼,而一般不會破壞JSON。
因此,無論以下行的都是精品:
{'data': '<script>alert(1)</script>'} # Normal, how I would do it
{'data': '<script>alert(1)</script>'} # unsafe data field which is documented as html encoded
我並不完全準確,但感謝您提出一個很好的觀點,即不應該在json之上進行編碼,而只是在(風險)屬性上進行編碼。我已經更新了我的問題,並明確了這一點。 –
關於你的答案,是的,那是其中一個選項。那麼出現的問題就是如何處理移動終端上的問題,例如?此外,在客戶端,無論輸入驗證如何,所有屬性都應該視爲存儲XSS類型的風險。我看過一些例子,人們在每個響應中實際發回2個json版本:編碼和原始。但不知道這是一個好主意。 –
我會更看重乾淨的API,並嘗試收緊我的JSON的數據洞察力,然後完整的JSON輸出。例如,我不會在驗證錯誤響應中「回顯」變量的輸入,以防止可能的注入。 (並且是的客戶應該把所有的領域看作是有風險的) – chickahoona
從這些「親密」的選民那裏聽到一些推理會很有趣:如何解決這種問題,其中不清楚最佳實踐是什麼。 –