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

Posted 2023-02-24

【中文标题】“过滤器输入，转义输出”对 PDO 是不是仍然有效

【英文标题】：Is "filter input, escape output" still valid with PDO“过滤器输入，转义输出”对 PDO 是否仍然有效

【发布时间】：2011-05-12 05:08:21

【问题描述】：

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

【参考方案1】：

是的，它仍然有效。

过滤不是为了防止安全漏洞，它是关于不使用垃圾填充您的数据库。如果您期待一个日期，请确保它至少看起来像一个日期，然后再存储它。

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

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

【讨论】：

“过滤不是为了防止安全漏洞”。这一点都不为过。

@ircmaxell 和@JW，所以我错误地认为过滤输入部分是为了防止 sql 注入？你是说它们是两个不同的问题？

@sami：绝对。你不需要过滤来防止注入（事实上，如果你是，它可能不会在所有情况下都起作用），你也不需要防止注入来过滤。它们不是相互包容的（虽然积极的过滤可以防止注入，但这不是它的意思）......

【参考方案2】：

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

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

还有其他情况，例如，如果您有一个电话号码字段，您可能希望对其进行过滤，使其采用您的应用程序使用的特定格式等等。

【参考方案3】：

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

【讨论】：

您能否告诉我您的意思是“SQL 注入不是唯一的问题”。我知道我需要转义输出，但是对于输入，除了 SQL 注入之外还有什么？我什么都没想。

@sami：很大程度上取决于您在做什么以及如何做，但系统中的用户输入通常会受到缓冲区溢出攻击或开发人员的其他事情的影响可能连想都不敢想，但平台本身可能没有配备好处理。这是罕见的，但经验法则仍然存在。永远不要相信用户发送给系统的内容。

【参考方案4】：

根据 sql-injection 和安全性，如果您使用绑定变量正确使用 PDO，则不需要清理。但是正如 Jani 指出的那样，根据您保存的数据，例如不允许使用 html 的文本字段，您可能想要清理数据，或者如果该字段应该是数字，则在其上运行 parseInt() 或某物。但这不是安全所必需的，而是您自己的数据库健全性所必需的。当有人试图将 html 放在评论中并且您将其吐出并看到 >

【讨论】：

从数据库中吐出来的时候，就是“转义输出”部分吧？

是的，传统上使用 htmlspecialchars();

【参考方案5】：

是的，它正在转义输入，但不像magic_quotes_gpc 那样立即转义。魔术引号是一种糟糕的安全方法。漏洞高度依赖于受污染数据的使用方式，您永远不可能拥有一个始终修复所有问题的功能。同样在应用程序的流程中，可能会出现另一个函数破坏magic_quotes的情况，例如stripslashes()、base64_decode()、urldecode()、htmlspecialchars_decode($var,ENT_QUOTES);甚至substr()。

简而言之，您必须始终在使用时转义输入。 pdo 和 adodb 做到了这一点，而且做得很完美。