Hi Kevin, On 25 February 2015 at 08:18, Kevin Ingwersen (Ingwie Phoenix) <ingwie2...@googlemail.com> wrote: > 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.
Er...it has an ini setting to create the whitelist? Also, blacklists would never work - there might as well be an infinite number of file extensions. > 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. So it does block "rare cases"? I dislike assigning rarity to security issues since that assumes we have actual hard data when we don't. All I can say definitively is that certain exploits in the area have been around since 2010. Most of the close-to-php reporting I've seen arrives around 2012. However, playing a numbers game about whether to implement a security protection or not is irrelevant. Either it is a security issue or it is not. It is. Getting your code audited is always a good idea, of course. > 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. PHP via EXIF jpeg field. MIME check would detect it as image/jpeg. Crackers have been using it in the wilds for years. MIME check of Stanislav's PHAR as a GIF would be detected as application/gzip for comparison since it's not a valid image. > 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. This last sentence is true enough. For some reason though, we still fix other entirely unrelated security weaknesses in PHP itself... Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
