“过滤器输入，转义输出”对PDO仍然有效

Question

我在“过滤输入，转义输出”之前读过这个，但是当我在PHP中使用PDO时，是否真的需要过滤输入？我认为使用PDO我不需要过滤输入，因为准备好的语句负责sql注入。我认为“转义输出”仍然有效，但“过滤输入”仍然有效吗？

Answer 1

是的，它仍然有效。

过滤不是要防止安全漏洞，而是关于不用垃圾填充数据库。如果您期望约会，请确保它至少看起来像存储之前的日期。

转义输出是为了防止安全漏洞（即XSS或跨站点脚本）。

所以是的，两者都非常重要，并且与SQL注入完全无关（尽管相当多的开发人员仍然混淆过滤与SQL查询的转义，因此仍然可能存在漏洞）......

Answer 2

根据您保存的数据，是的，它仍然有效。

例如，假设您有一个注释框，并且用户编写包含HTML标记的消息。在这种情况下，您通常希望从评论文本中删除所述HTML标记，即使它最终被转义（毕竟，它可能看起来不太好）。

还有其他一些案例，比如你有一个电话号码字段，你可能想要过滤它，以便它以你的应用程序使用的特定格式等等。

Answer 3

始终过滤用户输入。总是。也许您正在防范攻击，或者您正在执行业务规则验证等。请记住，没有任何技术或程序可以阻止所有攻击，只有它专门用于防止的攻击。 SQL注入并不是唯一要避免的问题。

Answer 4

根据sql-injection和security，如果你正在使用绑定变量正确使用PDO，那么你不需要进行清理。但正如Jani指出的那样，根据您保存的数据，例如不允许html的文本字段，您可能想要清理数据，或者如果字段应该是数字，则在其上运行parseInt（）或一些东西。但这不是安全所必需的，而是您自己的数据库健全性所必需的。当有人试图将html放入评论并且你吐出来并且你看到＆gt;时，这有点难看。 ＆LT;等

Answer 5

是的，它正在逃避输入，但不会立即像magic_quotes_gpc那样。魔术引用是一种糟糕的安全方法。漏洞很大程度上取决于被污染数据的使用方式，您永远无法拥有一个能够始终修复所有内容的功能。此外，在应用程序流程中，可能存在另一个函数破坏magic_quotes的情况，例如stripslashes()，base64_decode()，urldecode()，htmlspecialchars_decode($var,ENT_QUOTES);甚至substr() 。

简而言之，您必须始终在使用时撤消输入 。 pdo和adodb就是这样做的，它完美地完成了它。