正常來說,前台驗證和後台驗證是都要有的。
因為JS驗證不安全,如果有意為之,那麼完全可以繞過你的JS驗證。
如果你開發的是商業應用,那麼穩定性和安全性是相當重要的,而這裡就存在有安全性漏洞。
用戶端驗證:僅僅是為了方便,它可以為使用者提供快速反饋,給人一種運行在傳統型應用程式的感覺,使使用者能夠及時察覺所填寫資料的不合法性。基本上用指令碼代碼實現,如JAVASCRIPT或VBSCRIPT,不用把這一過程交到遠程伺服器。如果所有驗證都要通過請求伺服器,伺服器壓力太大了,沒有必要的事兒。
伺服器端驗證:構建安全Web應用程式所必需的,不管在用戶端一側輸入的是什麼,它可以確保用戶端送往伺服器最後處理的所有資料都是有效,以免出現一些漏洞或者不應該的異常。
比如說一個註冊頁面,填好註冊資訊後,你點擊提交按鈕,那麼它沒有跳轉就提示你填寫有誤,這一過程一般很快,返回時頁面也不晃動,但如果用伺服器端驗證,你填好後,可能會跳到另一頁面,返回得很慢,中間有可能有一段空白時段,返回後頁面出現重寫或晃動返回。用戶端驗證在提交到伺服器動態處理頁面前可以不用動態語言,而伺服器端驗證實際上是把資訊提交到伺服器上的動態網頁面裡才實現驗證。
從這個方面可以得知,用戶端驗證比較快些,可以實現本地機驗證,減少使用者的等待時間,如果提交到伺服器端驗證,使用者到最後等了幾分鐘才返回註冊不正確的提示,那豈不是讓使用者十分懊惱。所以,用戶端驗證又是比較友好的。但伺服器端的驗證更安全一些,因為代碼在用戶端是看不到的,而用戶端驗證的代碼是可以從網頁的查看“源檔案”HTML頁一清二楚的。
認為只在用戶端驗證就足夠的觀點,是建立在若干假設條件基礎上的。如:假設所有的Web應用程式使用者都同樣誠實,假設所有使用者將總是使用他們測試過的瀏覽器訪問Web應用程式,還有很多其他假設。然而,這樣的假設對於一個蓄意破壞者來說,無疑是一個搞破壞的極佳入手點。
事實上,通過在瀏覽器視窗中鍵入適當的URL,您可以發送任何"posted"表單,儘管可以通過禁用這些頁面的GET請求很容易阻止這樣的“表單”發送,但是卻不能阻止使用者通過類比一個表單提交資料來入侵你的系統。
拿使用者註冊表單來說,使用者在獲得註冊表單後,可以查看其HTML原始碼,並且將其儲存下來,將其中的JavaScript代碼去掉,另存新檔一個本地HTML檔案,再在本地運行,填寫資料,同樣可以成功達到向伺服器提交不合理資料的目的。
總結:
“用戶端驗證給使用者帶來方便,其存在的原因主要是對使用者考慮,但是它不能保證安全性,使用者可以輕易繞過。因此,對於一個安全的資料驗證方案,伺服器端的驗證是必須的,在設計應用系統時,必須考慮到這個要求。”