#21981 closed enhancement (wontfix)
Securing the uploads directory
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Upload | Version: | |
| Severity: | normal | Keywords: | |
| Cc: |
Description
Look at implementing something similar to an .htaccess file in the uploads directory with:
php_flag engine off
This may not work in every server scenario, but let's open the conversation, and some scenarios is probably better than none anyway.
Change History (7)
- Resolution set to wontfix
- Status changed from new to closed
Meant to close this. If there's a way to implement this without resulting in breakage, feel free to re-open.
In addition to the above, if PHP is running via fastCGI or any method other than mod_php, it will also create 500's.
Apache does not like data in it's .htaccess that it doesn't understand..
What about wrapping these directives in <IfModule> </IfModule>?
Replying to sirzooro:
What about wrapping these directives in <IfModule> </IfModule>?
my only thoughts there are
- mod_php.c vs mod_php5.c vs mod_suphp.c (although I'm sure 2 of them are more common than the other variations)
- would mean different behaviour between different hosts
- .php files shouldn't end up in the uploads directory to start with, if a select group of WordPress installations were to start having that behaviour, I can almost assure you that some plugins would rely upon it, leading to issues for others.
but more of that last one, rather than looking at the problem, solve the cause, why would .php files end up in the upload directory in most cases?
A compromised user account can use scripts in /uploads/ to exploit the installation. Not sure of another way around that, besides not letting accounts be compromised in the first place, which is obviously preferable but not always avoidable.
A compromised user account can use scripts in /uploads/ to exploit the installation.
If they get access to an Administrator WordPress login, they'll have access to the Theme/Plugin editor on most hosts, but unless the site specifically has ALLOW_UNFILTERED_UPLOADS enabled (it's off by default) they won't be able to upload a .php file.
That being said, since WordPress doesn't do mime checking on the uploaded files, it's still possible with some poorly configured CGI environments to upload a .gif (or similar) which contains PHP code to be executed - .htaccess can't help that scenario though.

Unfortunately, if AllowOverrides is set to not allow Options, this generates instant 500 errors.