我對Web頁/ WebMatrix與XSS的ASP.NET請求驗證有多少信任？

Question

我已經讀過（並同意）以下事實：沒有一種解決方案可以100％有效地抵抗XSS攻擊。 似乎我們所希望的最好辦法是停止“大多數” XSS攻擊途徑，並且可能具有良好的恢復和/或法律計划的后遺症。 最近，我一直在努力尋找應該或不應該接受的風險的良好參考框架。

閱讀了Mike Brind的這篇文章之后（一篇不錯的文章，順便說一句）：

http://www.mikesdotnetting.com/Article/159/WebMatrix-Protecting-Your-Web-Pages-Site

我可以看到，如果需要未經驗證的用戶輸入，則使用html清理程序也可以非常有效地降低XSS攻擊的途徑。

但是，就我而言，情況恰恰相反。 我有一個（非常有限的）帶有Web界面的CMS。 用戶輸入（經過URL編碼后）被保存到JSON文件，然后在可查看頁面上將其拾取（解碼）。 我在這里阻止XSS攻擊的主要方法是，您必須是少數幾個注冊成員之一才能完全更改內容。 通過記錄注冊用戶，IP地址和時間戳，我認為這種威脅已得到大部分緩解，但是，我想使用一個try / catch語句，該語句將捕獲asp.net的默認請求驗證程序所產生的YSOD。提到的方法。

我的問題是：我可以信任這個驗證人多少？ 我知道它將檢測標簽（從邏輯上講，此部分CMS未設置為接受任何標簽，因此，如果檢測到任何標簽，則會拋出錯誤）。 但是，這個天生的驗證器還能檢測到什么（如果有的話）？

我知道XSS可以實現，而無需碰到尖括號（或者完全沒有完整的標簽），因為可以保存，編輯html源，然后只需添加一個額外的代碼即可從客戶端計算機運行html源某些隨機標記的“ onload ='BS XSS ATTACK'”。

只是想知道如果一個人確實希望將其用作其反XSS計划的一部分（顯然是嘗試/捕獲，因此用戶看不到YSOD），那么該驗證器可以信任多少。 這個驗證器是不是很不錯，但是並不完美，或者這僅僅是“最佳猜測”，即只要有足夠的知識來知道XSS的人都將擁有足夠的知識，這種驗證將不會有什么實質性的意義？

- - - - - - - - - - - -編輯 - - - - - - - - - - - - - -----

在此站點上...： http : //msdn.microsoft.com/zh-cn/library/hh882339(v=vs.100).aspx

...我為網頁找到了這個例子。

var userComment = Request.Form["userInput"]; // Validated, throws error if input includes markup

Request.Unvalidated("userInput"); // Validation bypassed
Request.Unvalidated().Form["userInput"]; // Validation bypassed

Request.QueryString["userPreference"]; // Validated
Request.Unvalidated().QueryString["userPreference"]; // Validation bypassed;

每條評論：“ //已驗證，如果輸入包含標記，則引發錯誤”我認為，如果字符串包含任何被視為標記的內容，則驗證器將引發錯誤。 現在（對我而言）的問題真正變成了：什么是標記？ 通過測試，我發現單個尖括號不會引發錯誤，但是如果有什么（到目前為止，我已經測試過）在尖括號之后，例如

"<l"

這似乎是錯誤的。 我確信它會做更多的檢查，但是，我很樂意在請求驗證器的眼中看到哪些是合格的，哪些不合格。

Answer 1

我相信ASP.NET請求驗證是相當可信賴的，但是您不應該單獨依賴它。 對於某些項目，我將其啟用以提供額外的安全性。 通常，比起自己動手，最好使用經過廣泛測試/使用的解決方案。 如果我的客戶端遇到“ YSOD”（或自定義錯誤頁面）問題，我通常只禁用該頁面的.NET請求驗證功能。

這樣做之后，我會仔細確保對輸入進行清理，但更重要的是，對輸出進行編碼 。 因此，在我將用戶輸入的內容（或Web服務等-來自第三方的任何內容）推送給用戶的任何地方，它都包裝在Server.HtmlEncode（）中。 這種方法已經運行了很多年。

您提供的指向Microsoft文檔的鏈接非常好。 要回答有關什么是標記（或什么標記 ）的問題，請戴上黑客的帽子，然后查看OWASP XSS Evasion作弊表。

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#HTML_entities