简体繁体 English

PHP 的 FILTER_VALIDATE_EMAIL 是否提供足够的安全性？

[英]Does PHP's FILTER_VALIDATE_EMAIL provide adequate security?

原文 2012-05-03 14:23:19 5 2 php/ security

I have a page where I want to accept an email address in the GET parameters.我有一个页面，我想在其中接受 GET 参数中的电子邮件地址。 If I use FILTER_VALIDATE_EMAIL , am I still vulnerable to xss and javascript injection attacks, and the like?如果我使用FILTER_VALIDATE_EMAIL ，我是否仍然容易受到 xss 和 javascript 注入攻击等攻击？

I'm not asking if it's a good, or good enough, validator of email addresses.我不是在问它是否是一个好的或足够好的电子邮件地址验证器。 I want to know if one can still inject bad web code through arbitrary strings passed through it -- do I need to do additional filtering to prevent that?我想知道是否仍然可以通过通过它的任意字符串注入错误的 Web 代码——我是否需要进行额外的过滤来防止这种情况发生？

2 个解决方案

Yes, a valid email address can easily be used as the container for some carefully crafted strings that can be used to attack you.是的，一个有效的电子邮件地址可以很容易地用作一些精心制作的字符串的容器，这些字符串可用于攻击您。

Get out of the "filtering" mindset and get into the "escaping" mindset.摆脱“过滤”的心态，进入“逃避”的心态。 A universal "make it safe" filter simply doesn't exist.一个通用的“使其安全”过滤器根本不存在。 It cannot exist, because all escaping must be done in a context-specific manner.它不可能存在，因为所有转义都必须以特定于上下文的方式完成。

For example, if the email address will be output to a plain text document, then nothing is needed to be done.例如，如果将电子邮件地址输出到纯文本文档，则无需执行任何操作。 If it's being output into an html document, as a text node, then it needs to be escaped for an html context, so escape html special characters and entities.如果它被输出到一个 html 文档中，作为一个文本节点，那么它需要为 html 上下文进行转义，因此转义 html 特殊字符和实体。 If it's being put into an html document, and it's value will be inside of an html attribute, then very very careful escaping would need to be performed, and it would depend on which html attribute.如果它被放入一个 html 文档，并且它的值将在一个 html 属性内，那么需要非常非常小心地进行转义，这取决于哪个html 属性。 If it's being used in an sql query, then it needs to be escaped via a database specific escaping function, and even then you must escape differently if you're using it as a parameter value (ie, where someColumn = '$paramVal' ), vs a symbol name like a table name, a column name (ie, order by $myEscapedColumnName DESC ).如果在 sql 查询中使用它，则需要通过特定于数据库的转义函数对其进行转义，即使将其用作参数值（即where someColumn = '$paramVal' ），也必须以不同的方式转义, vs 符号名称，如表名、列名（即order by $myEscapedColumnName DESC ）。 and so on.等等。

It's all about context of use, not content of the string.这完全是关于使用上下文，而不是字符串的内容。 This goes for everything (not just emails or other user input), and it's not just a matter of security, but it's a matter of programming and syntax correctness.这适用于一切（不仅仅是电子邮件或其他用户输入），这不仅是安全问题，也是编程和语法正确性的问题。 Proper escaping is complicated, and takes a lot of time to learn, and careful thought and consideration when you code.正确的转义很复杂，需要花费大量时间来学习，并且在编码时需要仔细思考和考虑。 Many coders don't bother doing it due to the effort, and they are the ones who cause the company to get hacked.许多程序员因为努力而懒得去做，他们是导致公司被黑客入侵的人。

fyi, the email address spec allows quoted strings, so something you could inject strings like "<script>alert('xss')</script>"@example.com .仅供参考，电子邮件地址规范允许引用字符串，因此您可以注入诸如"<script>alert('xss')</script>"@example.com字符串。 The possibilities are obvious.可能性是显而易见的。

这应该已经足够好了，但自然地，在将它输入到数据库等时，您仍然应该逃脱它。您永远不知道 PHP 或 Apache 等中可能存在什么样的错误，无论如何都可能允许攻击发生。