【发布时间】：2010-04-29 10:23:56
【问题描述】：
pg_escape_string 或 mysql_escape_string 是否足以在将数据插入数据库表之前清理字符串？
【问题讨论】：
标签： php
【发布时间】：2010-04-29 10:23:56
【问题描述】：
“消毒”这个词非常值得怀疑。它暗示了一种世界观，其中某些角色是“坏的”，必须从源头上过滤掉。这是误导。
在 SQL 查询中获取合适格式的文本是将带外字符转义为其 SQL 文字形式，而不是删除“坏”字符。如果您想在进入应用程序时验证用户输入（例如，验证电话号码中没有字母，或者去掉不需要的控制字符），那很好。但这是一个特定于应用程序的验证问题，与任何与 SQL 转义或 HTML 转义有关的问题都完全不同。这些是输出阶段的问题。
mysql_escape_string 可能不足以安全地转义文本以包含在 SQL 字符串文字中。在可能使用某些东亚字符集作为编码或某些非默认 SQL 语法选项的连接上，它将生成允许 SQL 注入的格式错误的字符串。 mysql_real_escape_string 更好。但是，参数化查询避免了这个问题，并且在可用的情况下是首选。
pg_escape_string 使用连接，就像mysql_real_escape_string 一样，所以我希望它是安全的。但是，参数！在pg_ 你得到pg_query_params 所以没有理由不使用它们。
【讨论】：
对于数据 - 是的。只是不要忘记用引号括起来。
但参数化查询被认为更好，因为转义规则对于普通 PHP 程序员来说似乎太复杂了。
请注意，转义或参数与标识符或运算符无关。比如说，字段名称根本无法清理。转义对 LIMIT 参数也无济于事。
【讨论】：
没有。
为了防止 SQL 注入攻击，盲目调用mysql_real_escape_string 是不够的。来自手册：
mysql_real_escape_string() 调用 MySQL 的库函数 mysql_real_escape_string，该函数在以下字符前添加反斜杠：\x00、\n、\r、\、'、" 和 \x1a。
注意：mysql_real_escape_string() 不会转义 % 和 _。如果与 LIKE、GRANT 或 REVOKE 结合使用，这些是 MySQL 中的通配符。
【讨论】：
-
那又怎样？那你会推荐什么？
-
LIKE 转义是在字符串文字转义之上的另一层转义。 LIKE-escape 失败不是安全风险，但这意味着如果有人试图搜索“100% 很棒！”他们会得到所有结果，“100”后跟任意数量的字符，后跟“太棒了！”。即使您对文字转义问题进行了排序，LIKE 转义也很棘手。 stackoverflow.com/questions/2106207/…
（见其他地方的 cmets）
是的。
【讨论】：
不。您还可以使用 HTML Purifier http://htmlpurifier.org/ 清理输入以进行 xss 攻击。
【讨论】：
-
HTMLpurifier 和 ___real_escape_string() 做完全不同的事情
-
即使是为了防止 XSS 攻击，在输入上运行 HTML Purifier 也是完全错误的：它会弄乱有效的输入并且无法抵御所有攻击。使用文本字符串时停止 XSS 的正确方法是在输出阶段使用
htmlspecialchars()。 HTML Purifier 仅适用于需要让用户输入文字标记的极少数情况。