首先要來分享的是(前端)工程師面臨的資安挑戰的閱讀心得，在前傳與後傳中其實是有大部分雷同的內容，不過後傳比較像補充說明，因此如果有興趣閱讀還是建議從前傳看，再看後傳會比較有Feel~~(謎之音：騙肖ㄟ...技術文章還會有什麼Feel)。講師用了高橋流的簡報法，所以簡報數量驚人前後傳近250頁，不過由於內容簡要，所以看簡報有點就像在聽演講一般，可惜的是沒有看到LiveDemo，其實會關注這個議題是因為以往都會有固有觀念，資安不是應該在伺服器上解決，為什麼會提到前端網頁，但其實講師所重點的是JavaScript是運行在用戶端的，而且有跟後端的網站伺服器互動，因次如果相信前端所回傳的資料，不經處理，很又可能造成意想不到的後果，如2nd SQL Injection，SQL Injection是很早就有的議題，也相信很多開發者都會做基本的防護，但這些防護可能是針對對外的SQL Server而對內的SQL Server就不進行防護處理，因此當資料被從對外資料庫向對內資料庫傳遞時就有可能造成2nd SQL Injection，或者如果對於使用者在畫面上的輸入不做處理，直接回傳到前端網頁時，也可能造成前端網頁出現你所不知道的呈現，甚至對用戶端的破壞，所以講師提出了三個一定要遵守的原則：Filter Input、Escape Output、One Time Token。
Filter Input：這裡指的不是在前端透過JavaScript或Validation去驗證，而是當資料被送回伺服器時，應該被再次確認，不要相信前端送回的(驗證後)的資料，因為這個驗證結果可能是被竄改過的。
Escape Output：這裡指的是當資料要送到前端時，要編碼將特殊符號處理過再傳送，不要原封不動的將資料往前端瀏覽器送，因為你不確定這些資料是不是前端使用者惡意塞入的資料。當你透過編碼後，就能避免大部分的危險。
One Time Token：許多網站都會透過 Cookie 或 Session 進行 Token的紀錄，這裡的 Token指的是登入權證，當你重複使用相同的權證，就會讓有心人可以取得權證資料，進而破壞，但是One Time Token就可以避免。例如現在許多金融網站很流行的 One Time Password，甚至是Facebook或Google中也有用到相同的概念進行更高規格的帳號驗證。
這三點中在目前的ASP.NET程式開發中，是有些解決方案可以處理：
Filter Input：這點其實就是希望程式設計師要做好資料處理，就是對於每個來自於前端的資料，至少要做基本的處理，如長度判斷，文字內容判斷或者是要設定邊際，如只允許輸入8個字元，不是在 TextBox的 maxlength屬性中設定8就好，當資料被傳到程式裡時，就是在取TextBox.Text時就要再判斷一次，這樣才能避免惡意的資料被傳入。
Escape Output：這個部分在ASP.NET其實只要透過HtmlEncode將資料處理過，就可避免，甚至在ASP.NET 4中更加方便處理 Escape Output，只要將原本的
改為
就可以得到相同的效果。
One Time Token：則是透過使用一次的密碼來驗證使用者，這樣的機制在許多金融機構都有相關配合硬體的方案，不過最主要的是，要讓使用者不要使用萬年密碼(就是都不變更)，因此其實早就有這樣的機制可以被實作，如：Windows系統中的密碼複雜性原則，密碼用多久要變更一次？變更的密碼多少次內都不能重複？密碼必須由大寫英文、小寫英文、數字、特殊字元四種類型中的其中三種類型進行組合，更嚴謹的是要求各類字元不得少於幾個？這些都是在規劃密碼系統時可以被考量進去的。
其實資訊安全的關鍵在與開發系統時要以人性本惡的出發點來檢視，所有你覺得不可能的，其實都可能是最大的漏洞，如何讓漏洞減少，在於多做一些判斷，多做一些限制，看來麻煩點但是在資安與方便性地兩者選擇中，如何取得天平的平衡才是真正重要的。
留言