防範xss的正確姿式

防範xss的正確姿式

 xss攻擊是web攻擊中很是常見的一種攻擊手段。若是你尚未據說過xss攻擊，能夠先了解xss的相關知識和原理，例如: XSS)" target="_blank" rel="nofollow,noindex">https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) 。

防範xss攻擊的方式也十分簡單：轉義！

可是轉義的時機？是在持久化以前轉義呢，仍是讀數據以後escape呢？

我開始想也沒想就選擇了第一種方式，由於這種方法看上去一勞永逸，可是我如今愈來愈傾向於第二種方式。

實際上選擇第一種仍是第二種須要根據你的實際狀況來定。咱們知道xss攻擊是一種web攻擊手段，它的運行環境是在用戶的瀏覽器中，也就是說用戶的運行環境是不可控的。那麼在持久化以前進行轉義看上去彷佛不錯，由於咱們能夠利用filter或者interceptor攔截全部的寫入請求，統一進行轉義。這樣一來，咱們的業務邏輯就徹底不須要care轉義的問題了，由於咱們取到的數據已經都是轉義的過的了。

若是用戶的終端是可控的，好比：Native App，那麼入庫以前進行轉義就顯得畫蛇添足，由於全部的輸出方式都是在咱們的App中展示的，天然也就不會出現了xss攻擊的問題了。例如用戶在評論中輸入了<哈哈>，你以爲用戶但願輸出<哈哈>，仍是<哈哈>呢？ 結果是顯而易見的。

現實的狀況每每是複雜的，不會只有黑和白、0與一、native和web，更多的是它們交織在一塊兒，互相入侵對方的領域。基本上如今大部分的App都有分享功能，那麼惡意的用戶徹底能夠在評論中插入注入代碼，再將該評論分享出去，那麼其它被分享的用戶就有被攻擊的風險。解決的方法就是針對分享的數據進行全局轉義，事實上已經不少模版系統已經幫咱們考慮了這部分問題，例如Django和Jinja2的模版就是默認開啓自動轉義的。若是是先後端分離的場景，也能夠有前端來進行escape。

我推薦使用「入庫不轉義讀轉義」還有一個緣由，那就是前期轉義格式的不肯定性和後期輸出的多樣性。若是你正在正在開發一個rest服務器，你與App使用json格式通訊。爲了簡單，在開始業務代碼前，你對全部輸入數據按照html格式進行轉義。那麼你能夠十分放心分享出去的數據是安全的，由於全部的數據在持久化以前就已經轉義了，同時你會痛苦unescape給App的數據。若是那天老闆要求你以xml的格式輸出這些數據（多是其它系統的輸入要求，也多是打印報表），那麼你會更加痛苦。由於xml和html的轉義字符仍是有些不一樣的，你不得不先unescape回原始數據而後再按照xml的格式escape一次。若是這樣你以爲都還ok，那麼我開始有點佩服你了。若是老闆還要求你有更多的輸出格式，那麼你會更加痛苦，這仍是在沒有考慮輸入格式變化的狀況下。由於一個轉義的問題致使邏輯變得複雜，影響系統的穩定性是得不償失的。

最後，我來終結一下這兩種方式的優缺點：

轉義方式	優勢	缺點
入庫前轉義	一勞永逸	須要針對多端進行不一樣的輸出，靈活性不足，沒法應對後期數據格式的變化
讀取前轉義	簡單，靈活，能應對各類數據格式的場景	須要對每一個輸出數據轉義，人工處理容易遺漏

本人推薦第二種方式來防範xss攻擊。雖然須要對每一個輸出數據都進行轉義，可是若是你使用帶自動轉義的模版或者框架來處理的話，那麼就能夠極大的提升效率，又能夠規避安全的問題。最後仍是要提醒你們，安全無小事，即便你以爲沒有人會攻擊的系統，仍是要規避這些風險，安全是系統的基石。

參考文獻：

Why escape-on-input is a bad idea

When do you escape your data?

This article used CC-BY-SA-3.0 license, please follow it.