SQL注入預防 - 單行方法？

-2

我會盡量使用下面的示例代碼來保持這一簡潔和簡單。你認爲這是任何形式的SQL注入的問題......？SQL注入預防 - 單行方法？

$tmpVar = isset($_POST['somePostVar']) ? pg_escape_string(utf8_encode(preg_replace('/[^a-z0-9_]+/i', '', filter_var($_POST['somePostVar'], FILTER_SANITIZE_STRING)))) : 'error';

雖然我知道有一些可能在使用這四種方法殺/冗餘..我還是比較安全比遺憾，因此要求在這裏。

此結果的變量是用作

SELECT * FROM table_name WHERE someCol='$tmpVar'

現在我知道有這樣一個圍繞重複的問題，我也明白，同時不是在計算器上的一大海報...每日瀏覽器使用我是...

因此，使用pg_escape_string，函數utf8_encode符，preg_replace和filter_var ......這串只限於用下劃線爲字符.. 難道是與SQL注入的形式，容易折斷

utf8_encode也在這裏，因爲postgresql在使用pg_escape_string時可能會遇到問題。所以他們在這種情況下攜手合作。

來源

2014-02-25 Mayhem

請理解我確實知道每個功能的作用，有些可能會過度使用字符串......但有些情況需要考慮，其中一個簡單的修復並不總是那麼容易......問題是可以這個特殊的字符串仍然會被打破注入... – Mayhem

爲什麼你會把這一切搞亂？

只需像其他人一樣使用參數化查詢。見和bobby-tables.com。

你需要瞭解這個問題，不僅僅是把更多的隨機半理解事物放在它上面。例如對於使用SQL的例子完全錯誤，爲什麼你可能會這樣做後，你看着the documentation for it？

爲什麼你搞亂文本編碼？如果client_encoding正確，則不需要。

如果你正在做的事情等取代標識，或其他的東西，你不能使用服務器端的查詢參數，所有你需要做的就是雙任雙引號，所以：

this "identifier" name

變：

"this ""identifier"" name"

每個SQL標準。 PHP似乎爲此提供了便利功能pg_escape_identifier。

同樣，如果您必須在不使用參數的情況下提供引號（例如，默認值爲standard_conforming_strings），則文本中的引號會加倍。在ALTER USER ... PASSWORD ...等地方Pg不支持服務器端參數。但是，PHP驅動程序可能仍然支持這些客戶端參數，因此您可以像正常一樣使用參數化查詢，如果不是，則最好使用PHP的pg_escape_literal。

來源

2014-02-25 03:58:15

你應該閱讀關於使用pg_escape_string和它可以導致具有utf8編碼的postgres數據庫的問題。 – Mayhem

至於簡單地添加雙引號，並期望這使得用戶可調查詢安全....這是不安全的... – Mayhem

@Mayhem如果PHP需要你在使用這些功能時改變你的文本編碼，它甚至更多比平時崩潰，或者你的'client_encoding'配置錯誤。我希望看到一個合適的報告，以合理的詳細程度記錄此問題。如果您只是提到了6年前對文檔的評論，並沒有解釋其推理，那麼這並不是什麼好事，大多數人認爲'client_encoding'與默認的PHP編碼不匹配。 –

SQL注入預防 - 單行方法？

回答

相關問題