Here are my cents to this RFC, as it just keeps popping in in my inbox and its beginning to be one that I wish I could ignore.
First, … file extensions? A default Apache configuration and some Nginx configurations actually accept more than one file extension. This RFC does not include any way to specify a variety of extensions that should be blocked, ignored or treated else. Your PHP code is only so secure as you make it. If you are in need for such an RFC just to block a few „rare cases“, then I would rather suggest you to either check your source or hand it to a professional to get it counter-checked. Besides of that, it is never a good idea to let a user upload /everything/ that they want to. A proper MIME-type check can be helpful in these scenarios. Again, I would not vote for the RFC and I do not think positive about it, since I see it very unnecessary. Thus, if an attacker really wants to get into your business, they have more than one way to do so - for instance, exploiting the web server itself. Kind regards, Ingwie > Am 25.02.2015 um 05:57 schrieb Stanislav Malyshev <smalys...@gmail.com>: > > Hi! > >> I have to at least php:// >> php://input or php://stdin >> allows attacker script execution via POST if it's allowed >> by allow_url_include=On. > > allow_url_include=On means it's allowed. That's what "on" setting is > for. Production setting should always be "off". > -- > Stas Malyshev > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
