You probably want to also include in such security advice:
1) Never mix content and code
Keeping your content generating code separate from your static content
would avoid this problem entirely. Use of static-map and its ilk can
help to make it appear they occupy the same url tree, whilst avoiding
uWSGI having to determine if it should try to execute the code.
2) Never allow users to upload to code space.
This is a continuation of the above, but allowing users to upload
content to anywhere "trusted" files live requires raising your level of
security diligence significantly.
3) Next level: Store user provided content in a quarantine area.
At the very least, you can strip images of extra metadata, and even
recompress to save you hosting space, but you can also ensure some
vetting process before exposing yourself (and your users) to potential risk.
--
Curtis
On 25/02/17 01:03, Roberto De Ioris wrote:
Hello,
By default, PHP plugin allows run any content via PHP interpreter.
This behaviour can be restricted by "php-allowed-ext" config directive.
Sadly, default config (no php-allowed-ext directive enforced) opens
serious security
hole in some environments: Remode Code Execution via user uploaded
content.
Take example Apache config:
ProxyPassMatch "^.*\.php$" uwsgi://localhost:4000/
Despite strict extension matching in ProxyPassMatch, there is a problem:
If a non-privileged, authenticated user is able to upload i.e. his avatar
image to the site (valid .jpg with exif info), he can put PHP code into
EXIF
and execute it simply by fetching:
http://site.url/uploads/myavatar.jpg/anystring.php
Such attacks are very widespread in community sites (forums, boards) etc.
Default config is not secure enough. uWSGI configuration is a "monster",
php-allowed-ext directive could be overlooked by beginners (and even more
security-concious users) and open security hole.
Default config should impose strict extension match (".php" only), and
by overridable by first use of "php-allowed-ext".
BTW, I did not check cgi-allowed-ext... could be the same problem?
The best thing to do currently is improve documentation warning the admins
about configuration best practices.
This link:
http://uwsgi-docs.readthedocs.io/en/latest/PHP.html#advanced-configuration
could have more emphasis
Regarding cgi, it is the same thing, but it is something known for
sysadmins (it is one of the first step mapping the extensions to the
engine), so i do not think it is much of an issue, expecially because you
generally map the directory where you can safely execute cgi's.
Back to php, probably a default allowed-ext for ".php" is the best thing
to do, allowing the admin to disable it if needed.
_______________________________________________
uWSGI mailing list
uWSGI@lists.unbit.it
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
