-3

我将尝试使用下面的示例代码来保持这个简短而简单。您是否认为这对于任何形式的 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 时可能会出现问题。所以在这种情况下它们是齐头并进的。

4

1 回答 1

4

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

只需像其他人一样使用参数化查询。请参阅PHP 的 SQL 注入手册和bobby-tables.com。

你需要理解这个问题，而不是随便扔更多层随机的半理解的东西。filter_var(..., FILTER_SANITIZE_STRING)例如，与 SQL 一起使用是完全错误的，为什么在查看它的文档后可能会这样做？

你为什么要搞乱文本编码？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-25T03:58:15.600 回答