沒有像您所描述的過濾輸入的「唯一」方式,因爲沒有任何輸入本質上是無效的,甚至是惡意的。這完全是你做與重要的輸入。
例如,假設您在$_GET['field']
一些文本,你將要組成一個SQL查詢。您需要逃生使用mysql_real_escape_string()
(當然爲MySQL,)的值,像這樣:
$sql = "INSERT INTO some_table (some_field) VALUES ('" . mysql_real_escape_string($_GET['field']) . "')";
這轉義絕對關鍵應用到正在使用的SQL查詢的輸入。一旦它被應用,就像你在這裏看到的那樣,即使黑客的惡意輸入也不會對你的數據庫造成不良影響。
但是,如果您在頁面的某些HTML輸出中包含$_GET['field]
,則此功能無效且完全不可用錯誤。在這種情況下,功能htmlspecialchars()
很有用。你可能會這樣做:
echo "<p>Your comments were: " . htmlspecialchars($_GET['field']) . "</p>";
這兩個例子對於「黑客般的輸入」都是相當安全的。您不會將惡意數據插入到您的數據庫或HTML中。然而,注意這兩種轉義形式是完全不同的功能,每種功能都適合其使用。
相比之下,想象一下,如果您試圖同時「驗證」這兩個用途的輸入。您當然不能允許<
或>
個字符,因爲這些字符可能是跨站腳本等惡意HTML攻擊的一部分。所以,想要寫「我認爲1 < 3」的訪問者會受到阻礙。同樣,由於擔心惡意SQL注入攻擊,您無法引用引號,所以可憐的「Miles O'Brien」永遠無法填寫您的表單!
正確的輸入轉義很容易做,因爲您在不同的環境下使用它(它通常比驗證輸入更容易!)但結果更好。
無關你的問題,但對於驗證的E-mail正則表達式是不完整的。它將拒絕完全有效的電子郵件地址,如[email protected] – VoteyDisciple 2009-08-21 22:05:43
+1對VoteyDisciple的評論。這種不完整的電子郵件驗證方案是我遇到過的最令人討厭的設計決策之一。 – 2009-08-21 23:08:36
你是對的!感謝您的反饋。我將如何改變這個問題來解決這個問題? – pppglowacki 2009-08-22 02:22:11