I agree, there should be no limiting of unrelated language features to half-protect people who can't plan where uploads go.
Sent from my iPhone On Apr 9, 2012, at 6:11 AM, Ferenc Kovacs <tyr...@gmail.com> wrote: > > On Sat, Apr 7, 2012 at 10:48 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > Hi, > > The only valid reason for removing <?php from PHP script would be > security. > > > I disagree here. > What you are talking about here is > https://www.owasp.org/index.php/Unrestricted_File_Upload > So a malicious user can upload a file containing php code and fire a request > which will execute it. > Executing it can happen directly (you request the uploaded file via http), or > indirectly (you can trick some other script to include it aka LFI which is a > vulnerability in itself) > For preventing the uploaded files from be executed directly, one should put > the uploaded files to a separate directory and disable the php execution for > that directory via the web server config (php_flag engine 0) > > I don't see how would the removal of the open tags prevent the malicious user > from sending valid php code without opening tag. > I know that in your example you mentioned valid image files containing php > code with opening tag (in the image meta information), but that assumes that > the code properly checks that the uploaded file is a valid image (or any > other file format which can be injected with arbitrary php code). If that > check doesn't happen or not entirely safe, one could inject php code even if > we remove the opening tags. > So imo the correct defense against these kind of attacks is: > - properly handle the file upload paths, so the users can only upload files > to the given directory. > - turn off the php engine for that directory > - properly handle your file inclusions so you don't have LFI/RFI > vulnerabilities. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu
