2015-07-11 70 views
-1

我完全理解JavaScript應該用來增強用戶體驗,但是我有時會使用它來驗證輸入,例如檢查密碼文本框是否超過5個字符或檢查用戶名文本框中輸入的用戶名是否已經存在存在。正如你所想象的,如果密碼少於5個字符或用戶名已經存在,註冊按鈕將被禁用。什麼是驗證用戶輸入的正確方法?

但是,這可以從用戶瀏覽器改變,他們是否有更好的方式來驗證用戶的輸入?

我知道我可以驗證它全部通過服務器只是通過檢查文本框時,單擊註冊按鈕,但肯定它們必須是更好的方式,因此,用戶不能改變?

BTW:我使用Visual Studio的C#ASP.NET

而且,我是正確的認爲正則表達式也可以在客戶端改變

+0

假設客戶端的所有內容都是不可信的,這是正確的。即使沒有編輯dom也無法修改單選按鈕組或複選框等內容。是的,正則表達式可以修改。您需要客戶端(UX立場)和服務器端(實際安全)驗證。 – jdphenix

+1

基本規則是永不相信用戶。任何你放置在瀏覽器中的東西都可以在任何人離開你的服務器後被任何人操縱。因此,接受的做法是僅作爲用戶體驗機制進行客戶端驗證,並將服務器端驗證作爲實際驗證。 –

+0

無論你做什麼或者你不做客戶端,你都應該*也有*嚴格的服務器端輸入檢查。服務器是您防止非法輸入的最後一道防線。是的,任何事情都可以在客戶端進行修改。 URL和HTTP負載也差不多。這不會使Javascript正則表達式效率不高Trust Nothing;) – paulsm4

回答

-3

確實,客戶端代碼的本質是它是可操縱的。通過使用函數的Private和Privileged成員,您可以靠近通過控制檯防止更改代碼。 在構造函數中,特權方法分配爲this,並且只調用私有變量。就拿這個例子從crockford.com,

function Container(param) { 

    function dec() { 
     if (secret > 0) { 
      secret -= 1; 
      return true; 
     } else { 
      return false; 
     } 
    } 

    this.member = param; 
    var secret = 3; 
    var that = this; 

    this.service = function() { 
     return dec() ? that.member : null; 
    }; 
} 

的服務功能priviledged並能夠調用私有dec()方法,它可以訪問私有secret變量。 service是一種特權方法,因爲如果直接調用該方法,它將返回null.service而不是其有權訪問的變量的期望值secret

因爲服務器端代碼可能需要專門的結構化數據,如果沒有正確的javascript,將無法被接受,您可以在評估密碼時使用它。

5

驗證應在客戶端上完成和服務器。如果您選擇不使用內置驗證的框架,則可以編寫自己的正則表達式來執行此操作。

客戶端驗證可以被繞過,其主要目的是用戶體驗。 See here。服務器端驗證更難繞過。

+0

你絕對正確。此外,[OWASP Top 10](https://www.owasp.org/index.php/Top_10_2013-Top_10)(*強制性閱讀*)的無恥插件:https://www.owasp.org/index.php /類別:OWASP_Top_Ten_Project – paulsm4

1

永遠不要依賴於客戶端驗證。必須經常進行雙重檢查,一個在客戶端,另一個在服務器端。 Java腳本,J查詢和正則表達式可以爲你做到這一點。作爲一個側面說明,使用參數查詢。

相關問題