Hi On Wednesday, February 25, 2015, Stanislav Malyshev <smalys...@gmail.com> wrote:
> 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". Well, you fire those right over and then we'll have a debate worth having ;). > > 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. RFC does not target invalidated uploads. For heavens sake, it's a defense in depth measure not a sentient AI! > 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. > That is not true! The lack of validation is one of degrees. You are speaking in absolutes and ignoring partial effectiveness. Your example had ZERO validation. Yasuo's clearly targeted successful validation of an image. Not none at all. > > 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. > No it doesn't! You are misrepresenting this RFC as a magic wand. That is not the case and it is extremely frustrating to see you persist on this. Read my emails and read Yasuo's and then Dan's. Then we can have some sort of intelligible discussion. Paddy -- -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team Zend Framework PHP-FIG Representative
