輸入消毒VS驗證

我已經使用php（以及前端的js）對所有輸入數據實現了輸入驗證。我正在類型轉換，我可以驗證像正則表達式的電子郵件的東西，確保下拉列表值只是我期待的，而且在很多情況下，我只希望有一個字符串我有一個正則表達式，它只運行字母，數字和空格。任何不符合這些規則的結果都會導致表單失敗，並且沒有運行sql查詢。輸入消毒VS驗證

隨着中說，如果我的形式通過驗證我做它的輸入安全在我的分貝的假設（這我通過PDO做），然後逃脫輸出。

因此，既然說我爲什麼需要輸入清理？

來源

2013-07-04 Mike Rifgin

我會說，你是以下一個接受的方法。消毒和驗證（一起）並不總是必要的。雖然，我是深度防守的粉絲，所以我可能會這樣做。但「拒絕已知的不良」和「接受已知的好」也被認爲是可以接受的。 https://www.owasp.org/index.php/Data_Validation – cmt

如果你有非常嚴格的驗證服務器端，你不需要sanatize。例如。根據/^[a-z0-9] {5,25}驗證一個字符串$ /不需要任何消毒處理（刪除非字母數字字符將毫無意義，因爲它們不應該能夠通過）。

只要確保你可以驗證所有的數據，如果這是不可能的（例如，用HTML它往往是有點難度），你可以使用轉義策略或東西像HTML淨化器。

有關爲XSS預防逃逸戰略一個很好的概述：看到https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

對於不同安全威脅的一個想法： https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet

來源

2013-07-05 13:55:37 Arend

使用是的，我深諳在owasp上的內容。謝謝 –

你需要兩個。驗證輸入數據很容易在客戶端毆打，但對於不想破解你的合法用戶很有用。在將數據放入數據庫之前，將數據（所有數據，無論是輸入數據還是直接來自數據庫的數據）進行消毒處理，您認爲您應該能夠信任該數據。

即使您100％信任您的驗證並在服務器端進行（理論上，人們不應該能夠混淆數據），但仍然值得使用某種形式的消毒，因爲這是一種好習慣進入。

來源

2013-07-04 15:10:52

即使您對您的驗證過於自信，爲何要冒這個風險？ –

的確，我希望儘可能安全，所以爲了解決我的困惑，我問了這個問題。我在驗證和消毒之間唯一的區別是驗證在測試輸入時返回真或假，而消毒實際上取代了不需要的字符。我將最終對一個正則表達式進行驗證，然後使用相同的正則表達式對它們進行消毒，但使用preg_replace.Just看起來有點落後。 –

一個上下文，其中消毒可以進來它自己的是我無法驗證，即積極的自由文本字段，用戶可以輸入非字母數字字符...然後我可以看到消毒 –

輸入消毒VS驗證

回答

相關問題