PHP 代码注入
我的网站上运行着一个 php 脚本，它接受用户提供的输入并通过电子邮件发送。我通过剥离标签和斜杠来清理输入数据。但是，我没有使用此输入在数据库中输入数据，或执行包含、执行、评估或类似操作。如果我不做这些有风险的事情之一，恶意用户是否有可能通过 GET、POST 或 COOKIES 数组注入可执行的 php 代码？我几乎肯定答案是否定的，但我认为值得尝试询问更有经验的人。 :)
I have a php script running on my web site that accepts user-supplied input to send via an email. I am sanitizing the input data by stripping tags and slashes. However, I am not using this input to enter data in a database, or do an include, or an exec, or an eval, or anything like that. If I'm not doing one of these risky things, is it possible for a malicious user to inject executable php code through the GET, POST, or COOKIES arrays? I'm almost positive that the answer is "no", but I figured it was worth a shot at asking more experienced people. :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
先生，我可以向您介绍一下电子邮件注入
如何预防：http://phpsense.com/php/php-mail.html
注意：如果您使用用户提供的
数据仅在电子邮件正文中，
那么你就应该安全了。但
我的建议是永远信任
用户输入数据。
Well sir, may i introduce you Email Injection
How to prevent: http://phpsense.com/php/php-mail.html
Note: If you use the user supplied
data just in the body of the email,
then you should be safe from it. But
my recommendation is NEVER trust
user input data.
如果您没有在 SQL 语句中使用任何输入，没有将其写入文件，没有使用 eval 或 exec，或者包含它，则不，不可能注入可执行的 php 代码。
If you're not using any of the input in an SQL statement, not writing it to a file, not using an eval or an exec, or including it, no, it's not possible to inject executable php code.
在没有看到来源的情况下，没有人能确定，但有可能。代码执行通常在您使用
eval时发生。另请检查您是否在用户可以修改的字符串路径上使用 include 或 require 。哦，还有标头注入，它可能会影响您 http://www.securephpwiki.com/index.html php/Email_Injection
Without seeing the source, no one can tell for sure, but probably. Code execution usually happens when you use
eval. Also check if you use include or require on paths from strings which could be modified by users.Oh and there is Header Injection which will probably affect you http://www.securephpwiki.com/index.php/Email_Injection
我唯一能想到的就是打开register_globals，这将是一个高风险。
例如，如果您有以下注册全局变量的网址：
http://mysite/page/php?_SESSION=0，它将导致 PHP 覆盖会话全局变量：否则它只是电子邮件注入，您将必须留意 @amosrivera 提供的一个很棒的链接
the only thing that i can think of is having register_globals turned on, this will be a high risk.
for example if you had the following url with register globals on:
http://mysite/page/php?_SESSION=0it would cause PHP to overwrite the session globals:Otherwise its just email injection you would have to look out for, a great link supplied by @amosrivera
你已经在处理很多事情了。但我只是想分享我关于代码注入的经验。几个月前，我在网站的index.php 文件中发现了一些奇怪的代码行。当时我只是把那些线去掉了，但一周左右它们又回来了。然后，经过大量研究，我发现这是因为我的计算机中的某些恶意软件从我的 FTP 应用程序中窃取了我的 FTP ID/密码。它正在更改index.php 中的代码。之后，当我在计算机中重新安装操作系统时，问题就解决了。所以这可能是代码注入的一种可能性。
You already taking care of many things. But I just want to share my experience regarding Code Injection. Few months ago, I found some strange lines of code in the index.php file of my website. At that time I just removed those lines, but they came back again after a week or so. Then, after a lot of research I found that it was because of some mal-ware in my computer that hacked my FTP ID/Pwd from my FTP application. It was changing the code in index.php. After that when I reinstalled the OS in my computer and the issue was solved. So this might be one possibility of code injection.
最好不要从产生风险的条件来考虑这个问题，而是无论背景如何都采取预防措施。
但一般来说，用户提交的数据未保存到服务器上的任何位置，然后在 Web 应用程序本身中使用，这些数据会在请求结束时进行垃圾收集（在您的示例中，信息通过电子邮件发送，然后进行 GC）。但整体而言，注入是一个非常大的问题，最好不要笼统地考虑它。当然，用户可能无法注入 PHP，但即使是在 Web 应用程序中发布评论的简单不安全文本区域也可能会导致客户端 XSS。更好地进入实践。
作为一般规则，尽可能进行消毒。如果您在某些时候需要的话，我还应该提到用于 XSS 过滤的 HTMLPurifier 。由于您的表单用于发送邮件，因此您还应该在输入中放置验证码以防止自动发送。我还可以为您的邮件命令推荐 PHPMailer 吗？
It's really best not to think of this problem in terms of conditions that produce risks and rather perform preventative measures regardless of context.
Generally speaking however, user submitted data that is not saved to any place on the server and then utilized in the web application itself is garbage collected at the end of the request (in your example, the information is emailed and then GCed). But injection on the whole is a very large issue and it's best not to think of it in broad strokes. Sure, the user may not be able inject PHP, but even simple unsecured textareas that post comments into a web app can open you up to client-side XSS. Better to get into the practice.
Sanitize wherever possible as a general rule. I should also mention HTMLPurifier for XSS filtering should you at some point need it. Since your form is being used to send mail, you should also place a CAPTCHA on the input to prevent automated sending. May I also suggest PHPMailer for your mail commands?