Mobile app version of vmapp.org
Login or Join

Login to follow query

More posts by @Kimberly868

2 Comments

Sorted by latest first Latest Oldest Best

 

@Miguel251

Are you talking about allowing upload of content via the webserver or something else?

Regardless you should be ensuring that the permissions are already set up so that your PHP code can only write to designated locations (directories) seperate from your website content. This can be difficult on cheap, shared hosting.

Content upload

Frank's answer is mostly correct, but lacking detail and a bit misleading.

You MUST ensure that anything uploaded to the server will not be executed by the server. And you should provide multiple measures to prevent this.

You must treat any information supplied about the content with suspicion. File paths can be exploited (path traversal). User supplied mimetypes are essentially meaningless - don't be fooled by Microsoft's habit of treating a file extension and a mimetype as representing the same fact.

Even filenames should not be trusted - once you've validated the content, store the file using a path, filename and extension that you have generated.

The simplest solution to preventing execution is to ensure that uploaded content is stored outside the document root and all access is moderated by your site. This ensures that the file cannot be invoked remotely by simply typing the URL into a browser. It does not protect against local file inclusion vulnerabilties.

But if you have a cheap hosting package then this may not be an option. Alternatives are to store the file within the document root but in a transformed format (e.g. encrypted) with mediated access (protects against remote invocation and LFI). You can disable PHP processing (i.e. remote invocation) on Apache's main config or .htaccess using php_flag engine off . Again this does not prevent LFI.

For trivial validation of content, use finfo_file() and check the mimetype matches a whitelist. This just checks the first few bytes of a file though - and can be circumvented. For better protection, change the file type (e.g. jpeg to webp, gif to png, MSWord to HTML....) using a robust tool.

Something else

It really depends on the specifics of what you are trying to change.

You should NOT be creating executable code - particularly PHP or native binaries. Javacript and CSS are marginally less risky (use a templating system). Images, PDFs and audio/video should be relatively safe - but beware of the permissions you are granting to your PHP runtime of you are running local binaries to carry out operations.

10% popularity Vote Up Vote Down


 

@Cugini213

It is generally unwise to allow www or apache to have write access, however, this can be done safely by limiting the access to a single directory and not allowing any executables in that directory.

For example, the docroot of your php based site is /var/www/example.com
You would want your webserver setup so that the only php executable access point is /var/www/example.com/index.php and the only directory that the webserver can write to would be /var/www/example.com/files. This is often how php web applications handle image manipulation.

You would also want to have your webserver set so that no php files can be executed from inside the /files directory.

Also, you could pass these files through another source. php executes a shell script that writes the files, but this can be very complicated to do safely and it can add another vector of attack. Always remember, the more complicated a process the more things that can go wrong.

10% popularity Vote Up Vote Down


Back to top | Use Dark Theme