2017-06-03 31 views
0

我們有一個角度前端應用和asp.net核心web api後端的設置。 API使用json進行響應。 問題是,應該json屬性是否被html編碼?REST API - JSON內容應該是HtmlEncoded嗎?

我可以看到兩個原因:親和騙局。

另一方面,REST API應該是客戶端不可知論者(因此,不應該特別關心html),另一方面,僅依靠客戶端XSS預防感覺有點冒險。

想法?

+0

從這些「親密」的選民那裏聽到一些推理會很有趣:如何解決這種問題,其中不清楚最佳實踐是什麼。 –

回答

1

的幾點:需要針對不同上下文

  • 不同的編碼。所有數據的html編碼烘焙可能並不總是很好,特別是如果你以某種方式寫入Javascript上下文,而對XSS無用。所以從這個角度來看,我認爲JSON是數據,它只需要json編碼而不是html。當然,客戶端數據綁定或其他事情需要照顧編碼或安全綁定。
  • 如果在API調用中返回JSON,則響應的內容類型至關重要。它需要是application/json,否則如果json端點本身包含<script>等,它將容易受到XSS的影響。
  • 如果您將JSON數據寫入腳本塊(例如初始化變量),則會變得棘手。考慮以下幾點:
 
<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。避免這種情況並單獨下載數據會更好。

+0

這些都是非常好的一點!感謝那! content-type總是application/json,當然,我也喜歡json的數據只是數據(如果非html客戶端使用api,這尤其有意義)。所以,如果我正確地讀了你,你更傾向於客戶決定天氣它應該htmlencode json的一些部分或不? –

+0

是的,我認爲它不應該編碼除了編碼JSON本身的值,以使jaon結構完好無損。從那裏開始,數據消費者的工作就是處理任何進一步的編碼,例如。對xss的html或javascript編碼。做json值的html編碼的一個原因可能是如果你想將它寫入頁面來初始化一個js變量,但我認爲最好避免這種情況。 –

+0

是的,我同意。我會將你的文章標記爲答案,讓我們澄清一個細節:通過'將json值寫入頁面來初始化js變量',你究竟意味着什麼?謝謝! –

1

嗯,不得不考慮它,但我會這樣做: 沒有額外的HTML編碼JSON的頂部。確保您設置了正確的內容類型。如果您有「不安全」的數據字段,那麼您認爲這些數據字段特別危險,那麼您可以在文檔中將其指定爲HTML編碼,而一般不會破壞JSON。

因此,無論以下行的都是精品:

{'data': '<script>alert(1)</script>'} # Normal, how I would do it 
{'data': '&lt;script&gt;alert(1)&lt;/script&gt;'} # unsafe data field which is documented as html encoded 
+0

我並不完全準確,但感謝您提出一個很好的觀點,即不應該在json之上進行編碼,而只是在(風險)屬性上進行編碼。我已經更新了我的問題,並明確了這一點。 –

+0

關於你的答案,是的,那是其中一個選項。那麼出現的問題就是如何處理移動終端上的問題,例如?此外,在客戶端,無論輸入驗證如何,所有屬性都應該視爲存儲XSS類型的風險。我看過一些例子,人們在每個響應中實際發回2個json版本:編碼和原始。但不知道這是一個好主意。 –

+1

我會更看重乾淨的API,並嘗試收緊我的JSON的數據洞察力,然後完整的JSON輸出。例如,我不會在驗證錯誤響應中「回顯」變量的輸入,以防止可能的注入。 (並且是的客戶應該把所有的領域看作是有風險的) – chickahoona