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 <[email protected]> wrote:
>
> On Sat, Apr 7, 2012 at 10:48 PM, Yasuo Ohgaki <[email protected]> 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