[.NET] .NET Framework XSS 基本防護

近期在處理一項白箱源碼掃描的Stored XSS風險，

Source code是使用ASP.NET Webform撰寫，

GridView直接透過SqlDataSource來取得資料，

風險內容是從table取出資料後放上Textbox上的這部分被掃出沒有針對值做處理，

可能有XSS的風險在：

https://gist.github.com/yohey03518/e7e9ea1a33727f7e3bee1808a8eb08ed

不過經過將table內容放上alert語法實測後，發現並無問題：



Textbox控制項之資料並不會引發XSS問題(右側為GridView預設會針對資料所帶出的欄位)，

實際在Chrome上檢視原始碼來看(點選右鍵→檢視網頁原始碼，會另開分頁而非開發者工具)，

發現的確是被encode處理過(Textbox的value做了AttributeEncode)：



原因是.NET Framework(此處使用4.5.2)在「部分」的控制項上有自動做encode的機制(.NET Framework 2.0 經實測也有此機制)，

但像是Label控制項可就沒有此機制了：

https://gist.github.com/yohey03518/1127c97b62fbc4702aaca496142264ef



至於哪些控制項會自動encode，

先前網路上的資料目前已失效，

可能在使用時尚需個別測試測試。

至於要做HtmlEncode除了如下常用的寫法外



在.NET Framework 4之後有提供了更簡便的寫法(這邊以Label為例)：



發現有什麼不一樣嗎？



可以用一個半型的冒號(:)來做html encode，

實測後也發現的確有做了html encode，



此寫法也支援ASP.NET MVC 2 View的寫法。

回到了目前常用的Razor語法，



預設都是會做encode處理的，

至於若真的有需要將Html內容直接印在View上，

則可以使用Raw的語法來達成。



最後，即便框架已經針對XSS做了諸多防範，

並不代表源碼檢測無意義也不代表web無XSS風險存在，

唯有詳細了解源碼檢測掃出的風險內涵以及框架防範機制並且做實測，

才能在處理風險時做出正確的判斷。