On Fri, 2010-08-27 at 18:48 +0100, Ed W wrote:
> On 27/08/2010 18:05, Cliff Wells wrote:
> > Nevertheless, I've updated the MediaWiki entry.
>
> I'm still having problems getting to the wiki - no .js files are loading
> which is causing some wierd stuff to happen.

I do not see any issues... does anyone else have a problem?

> However, my opinion is that just adding try_files is only a partial
> fix. If some way is found to upload .php files (bad wikipedia config)

I don't think we should try to overcome people's intentional
configuration. Not only is it completely their fault if they go
through the difficulty of enabling a feature that is off by default, but
now we are attempting to impose our will on a user who has made a
specific decision. This is always a bad road in software.

> or some other exploit is found that can bypass the try_files then we
> still have an issue.

Not going to worry about such speculative future issues. If such an
issue arises it will need to be addressed as an Nginx patch, not a
configuration option.

>
> My mediawiki config does this:
>
> location ~ .*.php$ {
> include /etc/nginx/fastcgi_params;
> if ( $uri !~ "^/images/") {
> fastcgi_pass localhost:9000;
> }
> }
>
> Others have already pointed out that we can do better than my IF.
> However, your try_files, plus the explicit exclusion of the /images/ dir
> go a long way to secure mediawiki. Also I think the specific exclusion
> of the /images/ dir becomes quite self-documenting, whereas the
> try_files is quite a subtle fix?

It is subtle, but all fixes are, because the underlying vulnerability is
quite subtle. What user isn't going to look at that and say to
themselves "why do I need this if statement?". Just use the try_files
and add a comment to its purpose.

Cliff


_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx