On Sun, Feb 5, 2012 at 5:21 PM, Pierre Joye <pierre....@gmail.com> wrote:
> hi, > > I think we should remove eval at the same time then. As the risk is > exactly the same in both situations. Eval is just as evil and can be > avoided as well (or any other similar features, not sure if other exts > allow that). > > Cheers, > > https://wiki.php.net/rfc/remove_preg_replace_eval_modifier#but_we_don_t_remove_eval_either_do_we I think it would be very unwise to start bringing up that here, when the RFC author explicitly stated that his RFC is not about removing eval. >From my POV, the problem with /e is that it is easy miss the fact that using unfiltered user input in your preg_replace call can lead to arbitrary code execution. With eval() you explicitly state that you want this, and if you miss the security implications of your actions, you can blame nobody but yourself. Another difference is that as the RFC states, the /e modifier can be replaced easily with a callback, which would make the code even more clear, so it is an even better alternative. On the other hand, eval doesn't have such an easy alternative, you would have to generate and save the code and include it, which has the same security implications but it is much more tendersome, and it would also open up potential security implications (another process overwriting your temp file would cause arbitrary code execution for example, so one would need to use hard-to-guess filenames and/or exclusive locking, or using custom streams, etc.). To summarize /e has less use cases than eval and it has an alternative which provides better code, which isn't true for eval. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
