用于数据库插入的最安全的现代过滤器？答案

【问题标题】：Safest modern filter for database insertion?用于数据库插入的最安全的现代过滤器？
【发布时间】：2016-06-07 08:14:58
【问题描述】：

暂时忽略准备好的语句和其他实际插入数据库的方法，在插入之前清理输入的最佳当前方法是什么？

function filter($s) { return htmlentities(addslashes($s)); }

或

function filter($t) { return mysqli_real_escape_string($t); }

【问题讨论】：

在这种情况下 mysqli_real_escape_string 但是将参数绑定到准备好的语句要好得多：stackoverflow.com/questions/60174/…
mysqli_real_escape_string 仍然是更好的方法，但与正确使用准备好的语句相比，它很糟糕。在现代 SQL 应用程序中不应容忍任何形式的字符串转义。
htmlentities 完全错误。这样做的唯一目的是在网页上显示 HTML 时对其进行转义，它与数据库无关。
由于有时需要在页面上输出数据库中的内容，是否应该将mysqli_real_escape_string和htmlentities一起用于此类数据？
另外，我看不出这个问题的重点。准备好的语句是唯一防止 SQL 注入的方法，你为什么不想使用它？

【解决方案1】：

暂时忽略准备好的语句和其他实际插入数据库的方式，

好的，让我们将实际上实现安全性的最佳实践放在一边...

在插入之前清理输入的最佳当前方法是什么？

这是一个奇怪的问题！如果你有mysqli，你可以使用prepared statements，所以我不明白为什么有人不使用它们？

诚然，您需要接受用户数据并将其与 SQL 查询结合起来的用例范围很窄。 LIMIT $foo 是一个经典的例子（最简单的解决方案：使用 PHP 7 并且只接受 int 到该参数）。

另一个例子是SELECT * FROM table WHERE id IN (2, 3, 4, 5)。再一次，将用户输入转换为整数会消除这里的大部分攻击面。

整数很容易。字符串呢？

好吧，read this at least once。您应该非常熟悉字符集攻击，并确保您使用的是安全的字符集。

只要您遵循规定的建议，是的，您可以安全地使用mysqli_real_escape_string() 或PDO::quote()。

但说真的，请使用准备好的语句。如果你是separate data from code，你就不太可能犯错误。

function filter($s) {
    return htmlentities(addslashes($s));
}

这不仅是阻止 SQLi 的一个坏主意，而且是bad idea to attempt to strip XSS on insert。

最后，SQLi 和 XSS 是已解决的问题，preventing SQLi 的工具和策略与preventing XSS 的工具几乎没有重叠。混淆他们后果自负。

【讨论】：