问mysql准备的语句& html净化器耦合概念

EN

如果在不受信任的数据插入到mysql期间使用预先准备的语句，则不需要使用mysqli_real_escape_string函数。我说的对吗？

你明白重点了。准备好的语句有自己的逃逸过程。

如果我使用准备好的语句，同时从mysql db获取和显示数据作为html屏幕，(出于安全考虑)最好使用html净化器类，所以我应该使用html净化器类。我说的对吗？

你也是对的。当您打印html时，您必须确保它是安全的，因此它们是两种解决方案:一种是激进的解决方案:一种是用htmlspecialchars逃避每一件事，另一种是允许安全的html标记的软解决方案:使用htmlpurifier。

我还想让你向你介绍一条规则，它将给你带来一个安全和更舒适的网站:过滤器在逸出。

准备语句和htmlpurifier是为了“逃出”的，这意味着您将以输出可以理解的方式发送数据。

规则的一部分中的过滤器让您研究用户输入的内容。一个很好的例子是日期格式。也许你想让他们用英语输入一个Y-m格式的日期。如果他们没有，你的网站将无法工作，所以你必须要求他们再次输入的日期正确的方式。关于过滤，有一种方法需要记住：filter_var

是的，确实如此。

无论如何，mysqli_real_escape_string函数与任何保护都无关。

html净化器是一件好事，但你可以用懒惰的htmlspecialchars()函数调用来代替它，如果用户输入中没有HTML。

关于准备好的语句，唯一要提到的是:它们只涉及基本的标量值，对于复杂的值(如标识符(表和字段名)或数组)无能为力。

如果在不受信任的数据插入到mysql期间使用预先准备的语句，则不需要使用mysqli_real_escape_string函数。我说的对吗？

对，是这样

如果我使用准备好的语句，同时从mysql db获取和显示数据作为html屏幕，(出于安全考虑)最好使用html净化器类，所以我应该使用html净化器类。我说的对吗？

使用准备好的语句将保护数据库免受SQL注入的影响。它对XSS攻击没有任何作用。你需要一些防御措施。

由于“保护数据库”和“保护HTML”是完全不同的问题，解决方案的选择与另一种方案的选择无关。

使用基于白名单的过滤器构建在一个真正的HTML解析器(我假设HTML净化器就是其中之一)是一个明智的选择(如果你想要允许一些HTML)。