我将尝试使用下面的示例代码保持简短。你认为这对于任何形式的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时会出现问题。所以在这种情况下它们是齐头并进的。
答案 0 :(得分：4)
为什么要把这一切弄得一团糟？
只需像其他人一样使用参数化查询。请参阅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。