On 25 February 2017 at 01:05, Curtis Maloney <cur...@tinbrain.net> wrote: > You probably want to also include in such security advice:
I wish, more php applications would work with the `php-app =` option, i.e. they have a single file as entry-point. When I host php apps nowdays I typically look at using the applicaiton directory fully read-only, and with different tricks (symlinks, or configs) to make the data leave outside. I also set `php-allowed-ext = ` to the exact files I know are used for that application. * nextcloud accepted my patch for using a NEXTCLOUD_CONFIG_DIR env dir for it's config direcory, previously it had to be inside the code. * mediawiki can take a constant for this `php-constant = MW_CONFIG_FILE=/etc/something/something` * wordpress peoples have been ignorant - https://core.trac.wordpress.org/ticket/26592 * haven't looked at a good fix for drupal, so I just symlink sites/ outside the code directory some examples here: https://github.com/gdamjan/uwsgi-deployments comments welcome > 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 -- damjan _______________________________________________ uWSGI mailing list uWSGI@lists.unbit.it http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
