在保存到數據庫之前清理$ _SERVER ['HTTP_USER_AGENT']＆$ _SERVER ['HTTP_REFERER']？

我有一個反饋形式，它將採用幾個用戶輸入的字段以及PHP函數（如'user-agent'和'referer'）生成的幾個字段。

我的問題是應該輸入這些字符串之前？我意識到可以很容易地改變用戶代理和引用頁面，但是訪問者是否可以添加SQL注入類似於字符串，因此當PHP拉取這些信息時可能會破壞我的表單？

例如，如果用戶改變了自己的用戶代理或參考頁以包括串Robert'); DROP TABLE Students;--

2012-01-30 Eric

你不小心一個字：「...應該輸入這些字符串......」。 – 2012-01-30 16:24:46

mysql_query（）不支持查詢堆棧，攻擊者永遠無法執行drop語句。 SQL注入仍然是一個非常嚴重的問題，但是這種攻擊永遠不會起作用。 – rook 2012-01-30 17:54:35

簡單的答案：驗證/消毒/逸出一切（象客戶端的數據，例如）因爲一切可能被修改和邪惡或包含意外字符可能打破您的查詢（如Col. Shrapnel explanained）。

，以儘量減少風險，你應該也對使用prepared statements，而不是你自己構建SQL串（注：此並不意味着你可以離開了檢查）。

編輯：感謝您的評論，我已經改寫了整個第一句，而不是越來越多地減少它。

2012-01-30 15:37:06 oezi

那些來自服務器端的東西呢？ – 2012-01-30 15:53:28

@Col。 Shrapnel：謝謝你的提示，我應該清楚你不能相信任何外部數據。我重新說明了這句話，將其考慮在內。「所有」的 – oezi 2012-01-30 16:07:14

+500。 – 2012-01-30 16:11:30

始終清理/過濾任意從瀏覽器輸入。

假設所有的用戶都是邪惡的，你應該沒問題。

連接不一定來自瀏覽器 - anyone can write their own HTTP requests with a telnet client。這可能也有專門的工具，他們不會很難創建。

2012-01-30 15:37:32 ThatOtherPerson

任何輸入，句點。瀏覽器不是潛在惡意數據的唯一來源。即使數據庫可以注入自己，如果你正在往返數據。 – 2012-01-30 16:12:17

首先，我相信最好的做法是參數查詢查詢中的所有內容，包括自我生成的值。對我來說，它不會使查詢（幾乎）無懈可擊，但它會創建更好的和可讀的查詢。當您使用參數並稍後分配它們時，您會在代碼中使用更多的顯式邏輯，因此它的長期效果會更好。

更詳細的解釋可以在附加鏈接中找到：

2012-01-30 15:47:48 SimSimY

詞「的sanitize」是很模糊的，甚至欺騙。
事實上，根本沒有必要「消毒」字符串。你只需要格式他們。

所以，最好使用更精確的術語。

如果你在談論逃逸的，的答案很簡單：
你必須逃離你要投入查詢，儘管它的任何串的源，內容或目的。
這不是因爲一些愚蠢的漫畫兒童的恐怖故事。
查詢中字符串數據的恰當格式爲：必須將其括在引號中，從而轉義可能存在於數據中的這些分隔符。

請參閱？不同於所有其他答案告訴你只「消毒」用戶輸入，在現實世界中，你必須跳過每字符串。沒有用自己的問題來解決問題，「如果我應該清理一些東西？」。你應該。期。

注意對於任何其他查詢部分，如數字或標識符，轉義是完全無用的，並且將「消毒」任何東西。

同條規則適用於準備好的語句：
用它一如既往地爲任何數據，不僅爲「不可信用戶輸入」。

2012-01-30 15:52:30

回答