strip_tags() 和 mysqli_real_escape_string() 的安全性 [英] Security of strip_tags() and mysqli_real_escape_string()
问题描述
我参与了一个关于信息安全的学校项目，其中一项任务是用 PHP 编写一些安全页面.我的小组中没有人知道 PHP，不过这不是什么大问题，我们将学到足够的知识来创建所需的简单页面.
I'm in a school project on information security, and one of the assignments is to write some secure pages in PHP. None of the people on my group know PHP, that is not a big problem though, we'll learn enough to create the simple pages needed.
学生助理给出的提示之一是使用两个函数strip_tags() 和mysqli_real_escape_string().我认为这些是安全的，但如果没有深入的知识，我不确定.一些简单的谷歌搜索至少表明过去存在漏洞.作为任务的一部分是试图打破其他组系统，重要的是我们自己的系统是安全的，并在其他组的系统中找到可能的漏洞.并且大多数群体会盲目地使用这两个功能.所以我的问题是:
One of the tips the students assistants have given is to use the two functions strip_tags() and mysqli_real_escape_string(). I assume these are safe, but without indepth knowledge I don't feel certain. Some simple Google-searches reveals at least that there has been vulnerabilities in the past. As part of the assignment is to try to break the other groups systems, it is important both that our own system is safe, and to find possible vulnarabilites in the other group's systems. And most of the groups will use these two functions blindly. So my questions are:
strip_tags()中是否存在任何已知漏洞?mysqli_real_escape_string()中是否存在任何已知漏洞?- 是否有自然的地方可以搜索此类漏洞(除了询问 StackOverflow)?
- Is there any known vulnerabilities in
strip_tags()? - Is there any known vulnerabilities in
mysqli_real_escape_string()? - Is there a natural place to search for such vulnerabilities (other than asking StackOverflow)?
推荐答案
首先，我建议您使用 Mysqli 准备好的语句.这些比转义函数更安全，因为它完全将来自查询参数的查询结构.
First, I would recommend that you use Mysqli Prepared Statements. These are more secure than the escape functions as it entirely separates the query structure from the query parameters.
您可以使用 strip_tags 或 htmlentities 来确保没有恶意代码正在输出到浏览器.您可能还想通过某种过滤功能运行所有动态内容，然后再将其输出到浏览器.这是一个组织良好且有凝聚力的 OO 方法可以提供帮助的领域，因为您可以将所有动态内容分配给一个对象，然后该对象负责将输出呈现到浏览器，这样您就可以始终安全地知道您的内容是 XSS无需在多个页面中搜索数百个 echo 语句即可安全.
You can use either strip_tags or htmlentities to make certain that no malicious code is being output to the browser. You'll also probably want to run all dynamic content through some sort of filter function before outputting it to the browser. This is one area where a well-organized and cohesive OO approach can help because you can assign all dynamic content to a single object which is then responsible for rendering the output to the browser so that you can always feel safe knowing that your content is XSS safe without having to search through hundreds of echo statements across multiple pages.
然而，这两个建议确实只是涉及 PHP 安全性的冰山一角.还有许多其他问题需要处理，例如:
However, these two suggestions really only touch the tip of the iceberg when it comes to PHP security. There are a number of other issues that have to also be dealt with such as:
我建议您查看以下站点，以获取有关 PHP 安全主题的更多、更全面的处理:
I would recommend that you take a look at the following sites for additional, and more comprehensive treatment on the topic of PHP security:
- shiflett.org
- phpsecurity.org(这是 Chris Shiflett 的另一个站点，但我不确定他这里是否有其他内容这不在他的个人网站上)
- phpsec.org 没有我想要的那么多内容，但有一些有用的信息需要了解，例如使某些包含敏感信息(如数据库密码)的配置文件不存储在公开目录中.
- shiflett.org
- phpsecurity.org (This is another Chris Shiflett site, but I'm not certain whether he has additional content here that isn't on his personal site)
- phpsec.org Not as much content there as I would like, but there are some useful things to know such as making certain configuration files that contain sensitive information (like database passwords) are not stored in publicly available directories.
关于最后一项，如果可能的话，您将考虑使用 .htaccess 文件或它们的 IIS 等效文件，以确保只有您打算访问的文件是公开可用的.否则，您的所有其他安全措施都将无济于事.
On that final item, if it is possible, you will want to look into using .htaccess files or their IIS equivalent to make certain only the files you intend access to are publicly available. Otherwise, all of your other security measures will be vain.
更新:我想到了一些与您项目中的安全性相关的其他问题.如果您还记得不久前 Twitter 管理员帐户被黑客入侵的不幸事件，那么允许它发生的原因有多种，而这些原因都可以轻松解决.
Update: I thought of a couple other issues relating to security in your project. If you remember the unfortunate incident with a Twitter administrator's account being hacked a little bit ago, it was allowed to happen for several reasons that could have all been easily resolved.
1) 未限制的密码登录尝试.换句话说，如果用户尝试登录并失败，那么来自其 IP 的重复请求可能需要 2 秒来处理第二次，然后是 4 秒，依此类推.这使得机器人进行连续登录尝试变得不切实际.
2) 不需要安全密码.由于密码有更高的要求(所需的字符长度和类型，例如字母数字和特殊字符)，因此字典攻击变得完全不切实际，因为在破解密码时扔字典比提出随机数字字符串要容易得多和字母.此外，随着添加更多字符，破解密码的时间呈指数增长.
1) Password log in attempts where not throttled. In other words if a user attempts to log in and fails then a repeat request from their IP might require 2 seconds to process the second time, then 4 the next and so on. This makes it impractical for a bot to make continuous log in attempts.
2) Secure passwords were not required. As passwords have higher requirements (length and types of characters required such as alphanumeric and special characters), then dictionary attacks become altogether impractical because it is much easier to throw a dictionary at hacking a password than it is to come up with random strings of numbers and letters. Also the amount of time crack a password increases exponentially as more characters are added.
您可以查看 Jeff Atwood 的这篇文章，了解有关此特定问题的更多信息主题.
You can see this post from Jeff Atwood for more information on this particular topic.
这篇关于strip_tags() 和 mysqli_real_escape_string() 的安全性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
