> > One interesting thing with item #1 is that it allows for remote arbitrary > code execution even if no include-able path on a server is writable. This > comes into play if there's a supply chain attack on your app. Say, an > infected update on a CMS plugin. Get an eval() of a file_get_contents() of > a URL into the code and...well, you get code execution that (if you're > lucky) only leaves a trace in logs. If you have to write a file somewhere > first, then include it, you've got a bit more of a footprint.
You don't have to hit disk, or have any writable path. You can just create a stream wrapper <https://www.php.net/manual/en/class.streamwrapper.php> that stores the "files" in memory, and include them as you would include a regular file. Can you work around these restrictions? Yep, but it takes a bit more effort > than the current setup. It doesn't make a server secure by any stretch, but > it reduces its attack surface slightly, and reduces the universe of > malicious code that won't error out, forcing malefactors to work just a bit > harder. Disabling eval() really doesn't reduce the attack surface at all, if you ask me. Malefactors will quickly & easily adapt their tools, that script kiddies will use as before. — Benjamin
