Re: [RFC] Script only include/require

Hi Kevin, On 25 February 2015 at 08:18, Kevin Ingwersen (Ingwie Phoenix) <ingwie2000@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