SQL 注入预防 - 单行方法？

Question

我将尝试使用下面的示例代码使这一内容简短明了。您是否认为这对于任何形式的 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'

现在我知道周围有类似这样的重复问题，我明白这一点，虽然不是 StackOverFlow 上的主要海报...每日浏览器并使用我...

所以使用 pg_escape_string、utf8_encode、preg_replace 和 filter_var...这个字符串仅限于带有下划线的字母数字。它可以通过 SQL 注入的形式轻松破解

utf8_encode 也在这里，因为 postgresql 在使用 pg_escape_string 时可能会出现问题。所以在这种情况下它们是齐头并进的。

Answer 1

你为什么要把这一切搞得一团糟？

只需像其他人一样使用参数化查询。请参阅PHP's manual on SQL injection 和bobby-tables.com。

你需要理解这个问题，而不是随便扔更多层随机的半理解的东西。例如filter_var(..., FILTER_SANITIZE_STRING) 与 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。