Hi! > Your example omitted the image validation step which would have
Ah, right, and if I name it .zip, it'd be zip validation, and if I name it .pdf it'd be pdf validation, and if I name it .lol that would be LOL validation. You'd have to manually validate every type in existence and somehow invent validation for unknown ones. And it's not like I can't also make it a valid GIF/PDF/whatever - that has been done already. So you support this "security measure" by saying you can maybe plug the hole using other measures. Maybe you can, maybe (more probably) not but that does not redeem the insecurity of this "security measure". > again. It's not very fair to create a scenario with a total lack of > any security, and then ignore that your code's problem is that gaping > hole and NOT the minor extension filter on the far end. But that is *exactly* what this RFC is doing! The gaping security hole is include $argv[1] and that's where it should be fixed, not introducing temporary patches that prevent 1% of the scenarios and can be overridden within minutes. I don't see how it is not fair since the *only* scenario where it is useful is when your code *already* has the gaping security hole, otherwise this RFC has no utility as your includes are controlled by you so they already are php files. > indeed be preventable by his RFC. Please stick to what the RFC > actually claims to do. It claims to protect from file inclusion, by only allowing for include to operate on strings which end in .php, and then banning such files (ending in .php) from being handled by move_uploaded_file(). As I demonstrated (and this is I suspect not the only option) this does not actually offer any protection from LFI/RCE, as the end of the string given to include and the file on disk do not have to be the same. In my eyes, mechanism with such big BC break potential that is overridden in so trivial manner has little value. That even not considering upload doesn't even have to use move_uploaded_file() either. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
