我正在自学 PHP，并且已经了解了 strip_tags() 函数。这是提高安全性的唯一方法吗？
我是 PHP 新手，我正在这里学习教程： 链接
这是非常可怕的，用户可以在输入中编写 php 代码，并且基本上会搞砸你的网站，对吗？
好吧，现在我有点偏执，我宁愿立即学习安全最佳实践，也不愿在我养成了一些习惯后就试图将它们塞进去。
由于我是 PHP 的新手（实际上是两天前才学会的），所以我可以轻松学习几乎任何东西而不会感到困惑。
还有什么其他方法可以防止我的网站上出现恶作剧？ ：D
I'm new to PHP and I'm following a tutorial here:
Link
It's pretty scary that a user can write php code in an input and basically screw your site, right?
Well, now I'm a bit paranoid and I'd rather learn security best practices right off the bat than try to cram them in once I have some habits in me.
Since I'm brand new to PHP (literally picked it up two days ago), I can learn pretty much anything easily without getting confused.
What other way can I prevent shenanigans on my site? :D
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
开发 PHP 应用程序时需要记住几件事，
strip_tags()仅有助于其中之一。实际上，strip_tags()虽然有效，但甚至可能做超出需要的事情：根据情况，使用htmlspecialchars()转换可能危险的字符甚至应该是更好的选择。一般来说，这一切都归结为两个简单的规则：过滤所有输入，转义所有输出。现在您需要了解输入和输出的具体构成。
输出很简单，应用程序发送到浏览器的所有内容都是输出，因此每次输出不是您自己编写的数据时，请使用
htmlspecialchars()或任何其他转义函数。输入是 PHP 代码中未硬编码的任何数据：来自通过 POST 的表单、通过 GET 的查询字符串、来自 cookie 的数据，所有这些必须根据您的需求以最合适的方式进行过滤。即使来自数据库的数据也应被视为具有潜在危险；特别是在共享服务器上，您永远不知道数据库是否在其他地方受到损害，从而也可能影响您的应用程序。
过滤数据的方法有多种：白名单仅允许选定的值、基于预期输入格式的验证等等。我从来不建议的一件事是尝试修复从用户那里获得的数据：让他们按照您的规则进行操作，如果您没有得到您期望的结果，请拒绝请求而不是尝试清理它。
如果您处理数据库，则必须特别注意 SQL 注入：这种攻击依赖于您没有正确构造发送到数据库的查询字符串，以便攻击者可以伪造它们来尝试执行恶意指令。您应该始终使用转义函数，例如 mysql_real_escape_string() ，或者更好的是，使用带有 mysqli 扩展 或使用 PDO >。
关于这个主题还有很多话要说，但这些要点应该可以帮助您入门。
HTH
编辑：澄清一下，“过滤输入”我的意思是决定什么是好的，什么是坏的，而不是以任何方式修改输入数据。正如我所说，除非将用户数据输出到浏览器，否则我永远不会修改用户数据。
There are several things to keep in mind when developing a PHP application,
strip_tags()only helps with one of those. Actuallystrip_tags(), while effective, might even do more than needed: converting possibly dangerous characters withhtmlspecialchars()should even be preferrable, depending on the situation.Generally it all comes down to two simple rules: filter all input, escape all output. Now you need to understand what exactly constitutes input and output.
Output is easy, everything your application sends to the browser is output, so use
htmlspecialchars()or any other escaping function every time you output data you didn't write yourself.Input is any data not hardcoded in your PHP code: things coming from a form via POST, from a query string via GET, from cookies, all those must be filtered in the most appropriate way depending on your needs. Even data coming from a database should be considered potentially dangerous; especially on shared server you never know if the database was compromised elsewhere in a way that could affect your app too.
There are different ways to filter data: white lists to allow only selected values, validation based on expcted input format and so on. One thing I never suggest is try fixing the data you get from users: have them play by your rules, if you don't get what you expect, reject the request instead of trying to clean it up.
Special attention, if you deal with a database, must be paid to SQL injections: that kind of attack relies on you not properly constructing query strings you send to the database, so that the attacker can forge them trying to execute malicious instruction. You should always use an escaping function such as
mysql_real_escape_string()or, better, use prepared statements with the mysqli extension or using PDO.There's more to say on this topic, but these points should get you started.
HTH
EDIT: to clarify, by "filtering input" I mean decide what's good and what's bad, not modify input data in any way. As I said I'd never modify user data unless it's output to the browser.
strip_tags 并不是真正最好使用的东西，它不能在所有情况下提供保护。
HTML 净化：
http://htmlpurifier.org/
确实是处理传入数据的好选择，但它本身仍然无法满足适用于所有用例 - 但这绝对是一个很好的起点。
strip_tags is not the best thing to use really, it doesn't protect in all cases.
HTML Purify:
http://htmlpurifier.org/
Is a real good option for processing incoming data, however it itself still will not cater for all use cases - but it's definitely a good starting point.
我不得不说，您提到的 教程 在安全性方面有点误导：
这是无稽之谈。将值复制到局部变量并不比直接使用 $_GET 或 $_POST 变量更安全。
事实上，任何数据本质上都没有什么不安全的地方。重要的是你用它做什么。有完全合理的原因可以解释为什么您可能有一个包含
; 的 $_POST 变量。 rm -rf /.例如，这非常适合在 HTML 页面上输出或存储在数据库中。唯一不安全的情况是当您使用
system或exec这样的命令时。这时您需要担心正在使用哪些变量。在这种情况下，您可能想要使用白名单之类的东西，或者至少通过escapeshellarg运行您的值。与向数据库发送查询、向浏览器发送 HTML 等类似。在将数据发送到其他地方之前，使用适合目标的转义方法对数据进行转义。
I have to say that the tutorial you mentioned is a little misleading about security:
This is nonsense. Copying a value to a local variable is no more safe than using the $_GET or $_POST variables directly.
In fact, there's nothing inherently unsafe about any data. What matters is what you do with it. There are perfectly legitimate reasons why you might have a $_POST variable that contains
; rm -rf /. This is fine for outputting on an HTML page or storing in a database, for example.The only time it's unsafe is when you're using a command like
systemorexec. And that's the time you need to worry about what variables you're using. In this case, you'd probably want to use something like a whitelist, or at least run your values throughescapeshellarg.Similarly with sending queries to databases, sending HTML to browsers, and so on. Escape the data right before you send it somewhere else, using the appropriate escaping method for the destination.
strip_tags 删除所有 html 片段。更复杂的解决方案基于白名单（即允许特定的 html 标签）。一个好的白名单库是 htmlpurifyer http://htmlpurifier.org/
当然在数据库方面使用函数像 mysql_real_escape_string 或 pg_escape_string
strip_tags removes every piece of html. more sophisticated solutions are based on whitelisting (i.e. allowing specific html tags). a good whitelisting library is htmlpurifyer http://htmlpurifier.org/
and of course on the database side of things use functions like mysql_real_escape_string or pg_escape_string
好吧，可能我错了，但是...在我读过的所有文献中，人们都说使用 htmlspellchars 更好。
此外，还需要强制转换输入数据。 （例如，如果您确定它是用户 ID，则为 int）。
好吧，事先，当你开始使用数据库时 - 使用 mysql_real_escape_string 而不是 mysql_escape_string 来防止 SQL 注入（在一些旧书中仍然写成 mysql_escape_string）。
Well, probably I'm wrong, but... In all literature, I've read, people say It's much better to use htmlspellchars.
Also, rather necessary to cast input data. (for int for example, if you are sure it's user id).
Well, beforehand, when you'll start using database - use mysql_real_escape_string instead of mysql_escape_string to prevent SQL injections (in some old books it's written mysql_escape_string still).