> > 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. -- Roberto De Ioris http://unbit.com _______________________________________________ uWSGI mailing list uWSGI@lists.unbit.it http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
