On 25/02/15 00:38, Dan Ackroyd wrote: > As soon as you have any possibility of including a file uploaded by an > attacker, you are probably going to lose.
I think that this is perhaps the key here. My framework for new sites requires a user to log in before they can upload anything. So if your manager is worried about 'all this php malware' and your system allow unmanaged uploads ... all bets are off. The next thing I do with images is to create a thumbnail set, so only if you can get at the original file will there be a problem. I admit that I prefer to leave the file name unmanaged, but the option is to rename it original.xxx is also available. Anything uploaded that is not an image or can't be displayed as a thumbnail gets displayed as an icon, and viewing code as text gets the due diligence it deserves, so even if an approved user tries to add php script it will not be placed in a location where even if they could access it it could be run either directly or as an include file. I totally understand the basis of the RFC, I just don't see that creating a few more smoke and mirror obstacles to practices that are perfectly safe when used correctly but will add more work to 'web admins' who have to get around them even when their code is already safe? The code injection example only works on the basis "Imagine a piece of badly-written PHP code responsible for reading the image from disk and sending it to the browser:" This change does nothing to fix the badly-written code, but it is THAT which needs to be fixed rather than perfectly safe systems that 'disobey' this nannying? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
