ASP.NET保安系列 - 常被遺忘的伺服器端驗證

【ASP.NET保安系列前言】

我一直對資安十分敏感,而剛好身為一位網站開發人員,自然對系統架構的安全格外關注,過去已寫過不少文章討論網站設計上的安全議題。例如: ASP.NET防駭指南你的網站在裸奔嗎?游擊式的SQL Injection攻擊瀏覽器XSS防身術比武大會隱含殺機的GET式AJAX資料更新...  很遺憾地,常有題材可以討論,意味著因程式寫法疏失產生資安風險的問題沒消失過,而隨著技術推陳出新,又會有新陷阱冒出來。結論是,身為網站開發人員,永遠鬆懈不得,只要稍一犯錯,自認鐵打的安全網站當場變成紙糊的。

打算陸續整理一些開發ASP.NET網站時易遺漏的瑣碎安全細節,有些是從別人的個案中學到的,有些則是我自己犯過的錯,文章裡會分享自己處理該議題的經驗與做法,也歡迎大家回饋及指正,這些文章就姑且歸納為ASP.NET保安系列。

 

前陣子提到ASP.NET表單驗證控制項,順便再提一個重要觀念:

如果資料的嚴謹度很重要,就不應輕易信任客戶端傳來的內容!

過去看過不少案例,開發人員開開心心地在網頁上拖拉驗證控制項,測試欄位A沒輸入會被擋下來,欄位B有非數字就不能過關,接著在Button_OnClick()加入將欄位A, B寫進資料庫的程式碼,大喊一聲搞定,高高興興收拾書包回家。實際上,這樣的做法是有瑕疵的,它犯了一個錯 -- 只依賴客戶端的驗證便信任前端傳回的結果!

來個邪惡的示範:

<%@ Page Language="C#" %>
<script runat="server">
    protected void btnSubmit_Click(object sender, EventArgs e)
    {
        lblUpdteResult.Text=("模擬資料庫更新內容 = " + txtInput.Text);
    }
</script>
 
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>數字欄位輸入測試</title>
</head>
<body>
    <form id="form1" runat="server">
    請輸入純數字: <asp:TextBox ID="txtInput" runat="server"></asp:TextBox>
    <asp:RequiredFieldValidator ID="rv1" ControlToValidate="txtInput" runat="server" 
     ErrorMessage="不可空白" Text="*" />
    <asp:RegularExpressionValidator ID="cv1" ControlToValidate="txtInput" runat="server"
     ErrorMessage="本欄位只接受純數字" Text="*" ValidationExpression="[0-9]+" />
    <br />
    <asp:Button ID="btnSubmit" runat="server" Text="送出" OnClick="btnSubmit_Click" />
    <asp:ValidationSummary ID="vs1" runat="server" />
    <asp:Label ID="lblUpdteResult" runat="server" />
    </form>
</body>
</html>

RequiredFieldValidator與RegularExpressionValidator預設都會啟用Javascript寫的檢核函數,當使用者輸入內容不符合驗證規則時,可即時顯示錯誤訊息,並阻止表單內容送回伺服器端。

在一般狀況下,當欄位包含非數字時,按下送出鈕將無法送出表單。換句話說,伺服器端的btnSubmit_Click事件,只有在欄位通過驗證時才會被執行,認定txtInput一定是數字並直接寫入資料庫,應該是安全的才對。

BUT !

寫程式最機車的就是這個BUT! (偷學九把刀...)

如果不是一般狀況下呢? 使用者瀏覽器的Javascript引擎被停用或忽然故障,或是遇到某個很黑暗的人開啟了IE Dev Tools動點手腳...

登楞! 非數字內容一把推倒驗證器,就這麼闖進你的資料庫。

這是RegularExpressionValidator的錯嗎? 當然不是,Script端的保護機制是很脆弱,我們不應期望靠它阻擋惡意人士入侵或破壞,這是撰寫Client-Side機制時的重要原則。與安全性嚴謹性相關的機制,Client-Side可以發揮即時快速的回應,但一定要設想Client-Side機制失效的情境,在Server-Side構築最後的攔截防線!

而ASP.NET驗證器可貴之處也在於此,它同時提供了Javascript端與Server端的檢查,因此我們可省下為同一條驗證規則分別在前端與後端寫程式的麻煩。Button預設會觸發驗證邏輯(CauseValidation),因此表單在PostBack時會自動呼叫Validate(),我們在Click事件中透過Page.IsValid即可取得伺服器端的驗證結果。因此,要改善上述程式,只要多加一行:

    protected void btnSubmit_Click(object sender, EventArgs e)
    {
        if (Page.IsValid) 
            lblUpdteResult.Text=("模擬資料庫更新內容 = " + txtInput.Text);
    }

舉手之勞,但如此程式的嚴謹性才完整,開發時可別忽略了。

【延伸閱讀】

歡迎推文分享:
Published 28 January 2011 07:17 AM 由 Jeffrey



意見

# jain said on 27 January, 2011 07:40 PM

完全中了,我們的驗証常被破,謝謝您的分享,立刻改來用!

# demo said on 27 January, 2011 07:53 PM

寫網頁的應該要有認知不要相信從 前端傳來的一切資料,還有少利用 hide 欄位來放暫存資料

# 喜羊羊 said on 07 February, 2011 08:17 PM

感謝黑大分享這系列主題,有個問題想請教;若沒有使用 ASP.NET 驗證控制項的情況下,我們又該如何撰寫構築

前端與後端的驗證機制,並且網頁依然符合 ajax 的體驗快感。

# Jeffrey said on 08 February, 2011 04:59 PM

to 喜羊羊,好問題! 如果不用ASP.NET驗證控制項,如何做到前端及後端的驗證? 我的想法是: 沒有巧門,找其他替代控制項,不然自已寫,要做到完美,就只能用Javascript跟Server端各寫一次。我曾嘗試過Javascript驗證時透過AJAX呼叫Server端程式做驗證(這樣可以只寫一份在Server端),但是在即時性跟回應速度上會打折扣。另一個嘗試是使用Silverlight驗證,驗證完的結果加密後送至後端,後端永遠只接受加密後的格式(驗證可以只寫在前端),不過Silverlight一樣得送到User家裡執行,無法擺脫被破解或假造的可能。最後的心得--逃避不了跟ASP.NET驗證控制項做一樣的事,省不了事。

你的看法呢?

(必要的) 
(必要的) 
(選擇性的)
(必要的) 
(提醒: 因快取機制,您的留言幾分鐘後才會顯示在網站,請耐心稍候)

5 + 3 =

搜尋

Go

<January 2011>
SunMonTueWedThuFriSat
2627282930311
2345678
9101112131415
16171819202122
23242526272829
303112345
 
RSS
【工商服務】
OrcsWeb: Windows Server Hosting
twMVC
最新回應

Tags 分類檢視
關於作者

一個醉心技術又酷愛分享的Coding魔人,十年的IT職場生涯,寫過系統、管過專案, 也帶過團隊,最後還是無怨無悔地選擇了技術鑽研這條路,近年來則以做一個"有為的中年人"自許。

文章典藏
其他功能

這個部落格


Syndication