是“过滤输入，转义输出”吗？对 PDO 仍然有效
我在“过滤输入，转义输出”之前读过这篇文章，但是当我在 PHP 中使用 PDO 时，真的需要过滤输入吗？我认为使用 PDO 我不需要过滤输入，因为准备好的语句会处理 sql 注入。我认为“转义输出”仍然有效，但是“过滤输入”仍然有效吗？
I've read this before "filter input, escape output" but is filtering input really needed when I use PDO with PHP? I thought with PDO I don't need to filter input because the prepared statement takes care of sql injections. I think "escape output" is still valid, but is "filter input" still valid?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
是的，它仍然有效。
过滤并不是为了防止安全漏洞，而是为了不向数据库中填充垃圾。如果您期待一个日期，请在存储之前确保它至少看起来像一个日期。
转义输出是为了防止安全漏洞（即 XSS 或跨站脚本）。
所以，是的，两者都非常重要，并且与 SQL 注入完全无关（尽管相当多的开发人员仍然将过滤与 SQL 查询转义混淆，因此仍然可能受到漏洞的影响）...
Yes, it is still valid.
Filtering is not about preventing security vulnerabilities, it's about not populating your database with garbage. If you're expecting a date, make sure it at least looks like a date prior to storing it.
Escaping output is about preventing security vulnerabilities (namely XSS or Cross Site Scripting).
So yes, both are quite important and are totally unrelated to SQL Injection (although a fair number of developers still confuse filtering with escaping for SQL queries and hence can still be subject to vulnerabilities)...
是的，它仍然有效，具体取决于您保存的数据。
例如，假设您有一个评论框，并且用户编写了一条包含 HTML 标记的消息。在这种情况下，您经常希望从注释文本中删除上述 HTML 标记，即使它最终被转义（毕竟，它可能看起来不太好）。
还有其他情况，例如，如果您有电话号码字段，您可能需要对其进行过滤，使其采用应用程序使用的特定格式等等。
Depending on what the data you're saving is, yes it can still be valid.
For example, let's say you have a comment box and a user writes a message containing HTML markup. In this case you would often want to remove the said HTML markup from the comment text, even if it ended up being escaped (afterall, it probably won't look very nice).
There are other cases too, like if you have a phone number field, you might want to filter it so it's in the specific format your application uses and so on.
始终过滤用户输入。总是。也许您正在防范攻击，或者您正在执行业务规则验证等。请记住，没有任何技术或程序可以防止所有攻击，只能防止专门设计用于防止的攻击。 SQL 注入并不是唯一需要避免的问题。
Always filter user input. Always. Maybe you're protecting against attacks, or maybe you're performing business rule validation, etc. Keep in mind that there is no technology or procedure that will prevent all attacks, only attacks it was specifically designed to prevent. SQL injection isn't the only problem to avoid.
根据 sql 注入和安全性，如果您正确使用 PDO 和绑定变量，则不需要进行清理。但正如 Jani 指出的，根据您保存的数据，例如不允许 html 的文本字段，您可能需要清理数据，或者如果该字段应该是数字，则对其运行 parseInt() 或某物。但这并不是安全所必需的，而是为了您自己的数据库的健全性。当有人试图将 html 放入评论中，而你吐出它并看到 > 时，这有点丑陋。 < ETC。
As per sql-injection and security, if you're using PDO properly with bind variables, no you don't need to sanitize. But as Jani pointed out, depending on the data you are saving, such as a text field which doesn't allow html, you might want to sanitize your data, or if the field should be a number, running parseInt() on it or something. But this isn't going to be required to security, but for your own database sanity. It's kind of ugly when someone tries to put html in a comment and you spit it out and you see > < etc.
是的，它正在转义输入，但不会像
magic_quotes_gpc那样立即转义。魔术引号是一种糟糕的安全方法。漏洞很大程度上取决于受污染数据的使用方式，你永远不可能拥有一个可以始终修复所有问题的函数。此外，在应用程序流程中，可能存在另一个函数破坏 magic_quotes 的情况，例如stripslashes()、base64_decode()、urldecode()、htmlspecialchars_decode($var,ENT_QUOTES);甚至substr()。简而言之，在使用时必须始终转义输入。 pdo 和 adodb 可以做到这一点，而且做得非常完美。
Yes, it is escaping input, but not immediately like
magic_quotes_gpc. Magic quotes is an awful approach to security. Vulnerabilities are highly dependent on how the tainted data is being used, you can never have 1 function that fixes everything all of the time. Also during the flow of the application there may be a case when another function undermines magic_quotes, such asstripslashes(),base64_decode(),urldecode(),htmlspecialchars_decode($var,ENT_QUOTES);and evensubstr().In short, you must always escape input at the time of use. pdo and adodb does this, and it does it perfectly.