使用在线脚本混淆安全吗？
我正在考虑向大多数用户（非网络开发者）保护我的脚本，并且我遇到了一个对 php 脚本进行编码的在线服务。不过我不确定。
加密php脚本安全吗？如果编码的代码中有可疑内容怎么办？
I'm thinking of protecting my script to the mass majority of users (non-web dev savvy) and I came across an online service to encode php script. I'm not sure about it though.
Is it safe to encrypt php script? What if the encoded code has something fishy in it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果您打算分发 PHP 文件，那么我建议您不要这样做。它只会激怒那些想要修补它的人。
如果出于某种原因您不希望他们对其进行修改，则不要分发 PHP 文件。
如果您需要分发该文件并且不希望他们对其进行修改，那么我强烈建议您不要在 PHP 中执行此操作，而是使用 C 作为 PHP 的扩展来编写功能。
您会注意到，我在任何时候都不建议您实际继续“编码” php 文件。那不会给你买任何东西。
If you intend to distribute the PHP file then I would suggest that you do not do this. It's only going to irritate those that want to tinker with it.
If for some reason you don't want them tinkering with it, then don't distribute the PHP file.
If you need to distribute the file AND you don't want them tinkering with it, then I would highly suggest you not do this in PHP and instead write the functionality using C as an extension to PHP.
You'll notice that at no point do I suggest you actually go ahead and "encode" the php file. That's not going to buy you anything.
如果您希望混淆服务器端 PHP，最好的选择是使用商业产品，例如 Zend Guard（http://www.zend.com/en/products/guard/）。任何自制加密都没有丝毫安全性——您的代码可以通过相当简单的努力轻松地进行逆向工程。您链接到的页面没有任何可信度，它只是某人的副业项目。他们在保护您的信息方面没有责任或利益。
如果有人真的非常愿意的话，甚至这些商业产品（Zend Guard、ionCube、phpShield、SourceGuardian）也可以被解密。任何语言中没有任何工具或技术可以进行绝对安全的混淆，不存在“不可破解”的系统。一切都归结为随着时间的推移而努力。
如果它还不够重要，以至于不需要费心去做，那么你可能会在这个问题上浪费时间。此外，如果某些信息或代码的私密性绝对至关重要，那么您就不应该将其置于公共权限中。
[为了清晰起见进行了编辑]
If you are looking to obfuscate your server-side PHP, the best bet would be to use a commercial product such as Zend Guard (http://www.zend.com/en/products/guard/). Any home-brew encryption is not secure in the slightest - your code can be easily reverse-engineered with fairly trivial effort. The page you link to does not have any credibility, it is just someone's side project. They have no accountability or stake in protecting your information.
Even these commercial products (Zend Guard, ionCube, phpShield, SourceGuardian) can be decrypted if someone really, really wanted to. No tool or technique in any language can make absolutely secure obfuscation, there is no "unhackable" system. Everything boils down to effort over time.
If it isn't important enough to bother doing it right, then you're probably wasting your time on the issue. Further, if it is absolutely vital that some information or code remain private, you should simply not put it out into the public purview.
[edited for clarity]
最终，您需要信任加密方。如果您不信任他们（显然您不信任），则不要让他们访问您的服务器（通过执行他们的解密代码/您的混淆代码，可能还包含谁知道里面还有什么）。就这么简单，尽管可能不方便。
Ultimately, you need to trust the encrypting party. If you don't trust them (apparently you don't), then don't give them access to your server (through executing their decryption code/your obfuscated code, possibly with who-knows-what else inside). Simple as that, albeit possibly inconvenient.
php 通常运行在服务器上，用户无论如何都无法访问代码（无论是源代码还是任何其他表示形式）。没有理由在那里混淆它。
混淆 php 仅在将 php 代码提供给客户端的极少数情况下才有用。例如，如果您希望客户端能够运行自己的服务器，但不授予他们对代码的完全访问权限。
php is usually running on the server where the users have no access to the code(neither source nor any other representation) anyways. No reason to obfuscate it there.
Obfuscating php is only useful in the rare cases where you give the php code to clients. For example if you want clients to be able to run their own server but not give them full access to the code.
因此，看起来它所做的只是混淆代码，使其不可读。唯一真正有用的方法是防止有权访问代码的懒人阅读它。然而，它使用简单的函数来编码/解码，因此如果有人有权访问它，那么对其进行解码将是非常容易的。
这让我明白了我的观点... PHP 安全性的工作原理是不允许任何人访问源文件。如果不应该访问的人得到了它，那么这种“编码”的东西就不会给你带来任何好处。
So, it looks like all it does is obfuscate the code so it's not human-readable. The only way this would really be useful is to prevent lazy people who have access to the code from reading it. However, it uses simple functions to encode/decode, so it would be trivially easy for someone to decode it if they have access.
Which brings me to my point... PHP security works by not allowing anyone to have access to the source file. If someone who shouldn't have access gets it, then this "encoding" thing isn't going to do you any good.
OP 提到了对保护数据库连接细节的兴趣，应该记住，无论代码本身使用什么保护系统，开源的 PHP 引擎和组件库都会对可以实现的目标设置一些绝对限制。例如，如果 MySQL 连接详细信息隐藏在脚本中，那么只需使用对 MySQL 库或相关 PHP 模块包装器进行轻微修改的 PHP 构建运行脚本，就可以轻松地显示这些详细信息，而无需接近 PHP 脚本本身。在这种情况下，即使按照 Chris L. 的建议将细节隐藏在 C 模块中也无法提供额外的保护。使用 ionCube 和 Zend 等编译代码系统当然可以为源代码提供良好的保护，但只要数据触及 PHP 核心中的例程，它就可能被暴露。
显然，对于您可能发送敏感详细信息的任何在线服务，您应该进行尽职调查并尽最大努力确保其具有良好的血统。除此之外，如果OP所质疑的网站没有有效的https URL，应该立即警告说这是不行的，不仅仅是因为缺乏连接加密，还表明他们没有提供他们认为是的服务严肃的。
The OP mentioned an interest in protecting database connection details, and it should be kept in mind that no matter what protection system is used for the code itself, the PHP engine and component libraries being opensource sets some absolute limits on what can be achieved. If MySQL connection details, for example, are hidden in a script then these details could be trivially revealed without going near the PHP scripts themselves simply by running the scripts with a PHP build that had slight modifications to the MySQL library or the associated PHP module wrapper. Even hiding the details in a C module as suggested by Chris L. would afford no extra protection in this case. Good protection can certainly be given to source code with compiled code systems such as ionCube and Zend, but wherever data hits routines in the PHP core then it can be exposed.
Obviously for any online service where you may be sending sensitive details, you should use due diligence and make best efforts to ensure that it has a good pedigree. Apart from anything else, not having a working https URL for the site the OP questioned should immediately warn that it's a no-no, and not just for the lack of connection encryption but showing that they are not offering a service that they consider to be serious.