PHP 沙箱/清理传递给 create_function 的代码
我正在使用 create_function 在服务器端运行一些用户代码。 我正在寻找这两个中的任何一个:
- 是否有一种方法可以清理传递给它的代码以防止执行有害的内容?
- 或者,有没有办法指定此代码在沙盒环境中运行,以便用户无法使用其他任何东西。
谢谢!
I am using create_function to run some user-code at server end. I am looking for any of these two:
- Is there a way to sanitize the code passed to it to prevent something harmful from executing?
- Alternately, is there a way to specify this code to be run in a sandboxed environment so that the user can't play around with anything else.
Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
您可以使用 tonkenizer 来弄清楚代码将做什么,然后将某些功能和操作列入白名单。 我认为要使其万无一失最终会非常困难(或不可能),特别是考虑到 PHP 的灵活性:
唯一一种可以为您提供 100% 安全性(嗯,99.9%...)的沙箱是您可以使用的虚拟机之后就扔掉。
You could use the tonkenizer to figure out what the code will do, then whitelist certain functions and operations. I think it would end up being very difficult (or impossible) to make it foolproof, especially given PHP's flexibility:
The only kind of sandbox that will give you 100% security (well, 99.9%...) is a virtual machine you can just throw away afterwards.
我们使用分词器静态分析代码,并修改代码以对某些事情执行运行时检查。 这是通过分词器和基于分词器的脚本来完成的。 由于分词器与 PHP 实际使用的分词器相同,因此与编写自己的分词器相比,它会提高您的运气。
我见过人们使用正则表达式来尝试分析语言。 这是一个非常糟糕的主意。
但是...
由于 PHP 是一种非常愚蠢简单的语法,并且您可以访问标记器,因此您实际上可以通过禁止变量函数并只允许调用少量白名单函数来阻止大部分不良行为。 如果您不需要 OOP,那就更好了。
然而,我们并没有足够的信心来解决 100% 的问题,我们用它来为付费客户的后端用户提供沙箱,而不是地球上每个拥有键盘,也许还有恶意。
我也认为这里那些百分百认为这个想法是“不好的做法”的人需要得到线索。 这样做是有原因的。
We use the tokenizer to analyze code statically, as well as modify the code to perform runtime checks for certain things. This is done with the tokenizer and scripts based on the tokenizer. Since the tokenizer is the same one PHP actually uses, it improves your luck over writing your own.
I've seen people using regexes to try to analyze a language. This is a really bad idea.
But ...
Since PHP is a pretty stupid-easy grammar, and you have access to the tokenizer, you can actually stop most of the badness by disallowing variable functions, and only allowing a small number of whitelisted functions to be called. If you don't need OOP, even better.
However, we don't feel confident enough that we nailed 100% of the problems, and we use this to power a sandbox for the backend users who are paying customers, not every user on planet earth with a keyboard, and perhaps malice.
I too think the people here who poo-poo the idea 100% as "bad practice" need to get a clue. There are reasons to do this.
您无法可靠地清理用户输入 - 坚定的黑客会找到一些晦涩的方法来规避您的清理代码。
沙盒是可能的,但同样会造成严重后果。 如果你真的想安全,你应该为每个调用创建一个沙箱。 毕竟,有人可能会执行对沙箱的所有其他用户有害的虚假代码。
我认为你真的不想允许这样做。 这样想:您正在提供对服务器的编程访问!
You cannot reliably sanitize the user input - a determined hacker will find some obscure way to circumvent your sanitization code.
Sandboxing could be possible, but is equally crippling. If you really want to be safe, you should create a sandbox for each call. After all, someone could execute bogus code that is harmful to all other users of your sandbox.
I don't think you really want to allow that. Think of it this way: you are providing programmatic access to the server!
您可以尝试使用 Quercus(一种基于 Java 的 PHP 解释器)来创建安全的沙箱 PHP 环境。 您可以使用 Rhino 对 JavaScript 执行相同的操作,因此我认为使用 Quercus 也可以实现这一点。
You could try using Quercus, a Java based PHP interpreter, to create a safe sandboxed PHP environment. You can do the same for JavaScript using Rhino, so I think it might be possible with Quercus.
您可以考虑创建一种用户可以使用的自定义语言。 然后由您来创建支持的函数库,这些函数很可能只是 PHP 原生函数的包装器。 但即便如此,使其防黑客或简单地工作充其量也是一项乏味的工作。 也许您应该重新评估为什么您希望用户拥有代码访问权限? 如果您需要有人讨论这个问题(或者更新您的问题,我猜?:),我很乐意提供帮助,
希望您能解决这个问题!
-戴夫
You could consider creating a custom(ized) language that your users can make use of. Then it's up to you to create the library of supported functions that could very well be just wrappers of PHP's native functions. But even then, making it hack-proof or simply working is a tedious job at best. Perhaps you should re-evaluate why you want users to have code access in the first place? I'd love to help out if you need someone to discuss this with (or update your question, I guess? :)
Hope you can work it out!
-Dave
这是 GitHub 上的一门课程,在早期阶段可能会有所帮助,但看起来很有希望。
https://github.com/fregster/PHPSandbox
The is a class on GitHub that may help, early stages but looks promising.
https://github.com/fregster/PHPSandbox
总的来说,无论你采取什么保护措施,这都是个坏主意,而且太危险了。 最好创建一种仅限于用户可以执行的操作的伪语言。
Overall bad idea and too dangerous IMO, no matter what protections you put into place. Better create a pseudo-language limited to exactly what users are allowed to do.
http://php.net/runkit
http://php.net/runkit