使用PHP eval合成动态类时有哪些风险?

我正在阅读:什么时候(如果有的话)是eval而不是邪恶?和其他一些人在网上指导何时使用eval,何时不使用eval。 这些帖子都没有真正回答我关于运行时动态类合成的安全问题的问题。 </ p>

背景:由于我们不能使用PHP 5.4特性在类中正确混合,我们需要另一种解决方案来获得动态混合。 所以我们在Github上找到了这个特殊的类: https:// github。 com / wellspringworldwide / PHP-ClassMixer / blob / master / ClassMixer.php 完全符合我们的要求。 </ p>

对于潜在的安全风险,我不是真正的专家来评估此类代码,但Stackoverflow上的某些人可能知道此类方法存在的风险。 </ p>

据我所知,只有在</ p>


  1. 时才会给出使用eval进行类组合的安全性问题的基础。 要混合到另一个类中的类可以从外部访问和修改,例如文件或RPC访问</ li>
  2. 用户可以访问正在运行的上下文,即周围的代码加载插件代码</ li>
  3. 用户可以访问应用程序工作内存并更改数据。</ li>
    </ ol>

    我们的应用程序中没有给出这些情况,但我是 不确定在使用eval时我们还需要考虑其他条件!?</ p>

    谢谢。</ p>
    </ div>

展开原文

原文

I was reading : When (if ever) is eval NOT evil? and a few others guides on the net when to use eval and when not. None of this posts could really answer my question about security concerns in regard of dynamic class compositing at run-time.

Background : As we can't use PHP 5.4 traits to properly mixin in classes into each other, we needed another solution to get dynamic mixins. So we found this particular class on on Github : https://github.com/wellspringworldwide/PHP-ClassMixer/blob/master/ClassMixer.php which does exactly what we want.

I am not really an expert to evaluate such code in regard of potential security risks but maybe somebody on Stackoverflow knows what the risks are of such methods.

As far I understood, the base for security concerns with this method of using eval for class composition are only given when

  1. The class to be mixed into another class is accessible and modifiable from outside, for instance file or RPC access
  2. A user can gain access to the running context, ie, the surrounding code loads plugin code
  3. A user gains access to the applications working memory and alters data there.

None of these circumstances are given in our application but I am not sure there are other conditions we need to think about when using eval that way !?

thank you.

1个回答



Eval基本上是坏的,因为它是 eval()</ code>:D </ p>

不认真:</ p>

你永远不应该撰写一些来源并把它扔进eval。 一旦构成源的脚本具有任何依赖数据源(如数据库后端),文件系统读取(尤其是文本)文件或(甚至更糟)某些表单数据,就会有注入侵入性和破坏性代码的可能性。 (例如; exec('rm -rf /'); </ code>)</ p>

使用装饰器模式可能会帮助你。
请阅读这个那个作为理解装饰器模式的底漆。</ p>
</ div>

展开原文

原文

Eval basically is bad because it's eval() :D

No seriously:

You should NEVER compose some source and throw it into eval. As soon as your script composing the source has any dependent data sources like a DB backend, the file system reading (especially text-)files or (even worse) some form data there's always the chance of invasive and damaging code being injected. (e.g. ;exec('rm -rf /');)

Using the Decorator Pattern might help you out. Please read this and that as a primer to understanding the Decorator Pattern.

drf16571
drf16571 几乎所有这些,包括日志记录,变量解析器,调试,权限描述符以及我需要添加到现有类的许多其他内容。 问题是静态代码生成器是无用的,因为即使要混合的类也是如此。
6 年多之前 回复
dongmanzui8486
dongmanzui8486 那么你的课程应该服务于什么目的? 肯定有代码生成器,例如 在学说或symfony。 也许我不太明白,你想做什么。
6 年多之前 回复
dongpan1365
dongpan1365 嗨,谢谢你的回答,但我很抱歉,除了eval之外,它并不是真正揭示安全隐患。 然后装饰器模式很好,但这不是真正的条件/动态类堆栈在运行时,也非常有限加上它创造了更多的膨胀,我们想避免。 再次感谢!
6 年多之前 回复
Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问
相关内容推荐