Page MenuHomePhabricator
Create Task
Maniphest T10597

Custom Project query results in . url which nginx blocks
Closed, ResolvedPublic
Actions

Description

It can be argued this is not Phabricators problem, however I would argue that this configuration situation is so common that Phabricators behaviour is a problem for many of us.

centos 6
nginx 1.x from webtatic
php 5.6.x from webtatic
phabricator 2c67d9c8ace2800ec618549963c4036e92cb3a9b (Fri, Mar 4)
arcanist 1439aaa871837031faa1ef26b81f1fb08e4a41e7 (Fri, Mar 4)
phutil 76425eaa812572cc02487db79f2dd43d93e3085f (Fri, Mar 4)

Problem:

Generated Project query had a . at the start of a URI path, which resulted in my nginx config returning a 403 Forbidden.

Steps to reproduce:

  1. Went to Projects
  2. click on Active
  3. Click Edit Query
  4. Select the Project briefcase Icon
  5. Clicked Execute Query
  6. Got a 403 with the url: https://phabricator.mynetwork.local/project/query/.hmmCj2i6C9j/

Why I think this is Phabricator and not my configuration problem:

It is extremely common to have nginx configuration to hide .htaccess, .svn, .gitignore, .idea and a plethora of other files that are meant to be hidden from being exposed through HTTP. Many projects, tutorials and guides recommend doing this, and here is mine, which I believe I may have gotten from the default CentOS' webtatic repo nginx configuration ships with:

# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
location ~ /\. {
  access_log off;
  log_not_found off;
  deny  all;
}

Yes I fixed the issue by editing my nginx config, but it was not obvious what was going on at first. It could be argued that Phabricator forced me to make my nginx config less secure. I think phabricator could easily implement a fix for this and save a lot of us headaches.

The Fix:
Ensure that any generated url token when making custom queries (probably not just for Project) do not start with a ..

Sorry I can't contribute a patch at this time. :(

Related Objects
Search...

Event Timeline

ofbeaton created this task.Mar 15 2016, 11:55 PM
chad added a subscriber: chad.Mar 16 2016, 12:20 AM

It is extremely common to have nginx configuration

Can you give a specific example we can reproduce, which distribution specifically? Nothing offhand is coming up for me to verify this.

chad added a comment.Mar 16 2016, 12:31 AM

This is what I see on Ubuntu for default conf files for nginx, it's both commented out and restricted to .ht:

# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
#       deny all;
#}
chad added a comment.EditedMar 16 2016, 12:35 AM

Also, we link to . files elsewhere in Phabricator, so if we change Project URLs, this webserver config would still break other parts of Phabricator, like linking to .gitignore in your repository.

https://secure.phabricator.com/diffusion/P/browse/master/.gitignore

ofbeaton added a comment.Mar 16 2016, 1:52 AM

You already gave one @chad, on Ubuntu if the sysadmin uncomments that section, then any link starting with .ht would be blocked.

Notice that my completely randomly generated link started with .hm already, so I am guessing .ht is not out of the question at all.

  • I just checked another system we have running centos 6 and apache22 (from centOS 6) and it similarly blocks \.ht but I don't know if this was commented out originally or not. Even if it was, I imagine many admins would uncomment it.
  • I also just checked the current webtatic's files for nginx and it has a commented out section for blocking \.ht. I imagine many admins uncomment this.

So either it used to be \. or the admin of this particular system I was on was overzealous with the regex. In general it seems this kind of regex is part of security hardening an install that "all good admins should follow".

  • I am not proposing that you break existing . urls, merely that you do not randomly generate new ones that start with a ..
  • I do realize that if the admin blocks \.htaccess then viewing your .htaccess file in a repository would also return 403.

However that is more clear why it would be blocked, then a randomly generated url that just happens to start with .ht or whatever . variant regex the admin happens to be using.

My feeling is that this would be a small change that would stop some head scratching for end users, who do not deserve to be punished for this.

chad added a comment.Mar 16 2016, 1:56 AM

The correct solution for us would be to detect the servers misconfiguration and raise a setup issue asking the admin to resolve.

ofbeaton added a comment.Mar 16 2016, 2:00 AM

I'd be OK with that. I already got our admin to resolve the problem for my install, so I only raised this thinking it would help others. A server configuration warning would also have worked to have me fix this before users encountered it.

But you really consider the blocking of \.ht to be a misconfiguration? I find it hard to believe that all these distros ship with optional pre-templated code to do it if it's such a mistake.

epriestley closed this task as Resolved.Mar 16 2016, 2:05 AM
epriestley claimed this task.
epriestley added a subscriber: epriestley.

We'll consider adding a setup issue if we see other users having issues with this. Previously, we haven't, so we presume users having or uncommenting these blocks in the wild to be very rare.

See T2226 and linked tasks for a collection of other server self-checks.

epriestley mentioned this in T11553: Add various "make an HTTP call" setup checks, and run them in parallel.Aug 29 2016, 4:21 PM
epriestley added a parent task: T11553: Add various "make an HTTP call" setup checks, and run them in parallel.
Phabricator · Built by Phacility