Re: proxy cache key и fastcgi cache key

["S.A.N" <nginx-forum@xxxxxxxx>]

Для убедительности, приведу ещё такой пример.
Есть бекенд приложения, которое обслуживает множество хостов, всех этих
хостах fastcgi_pass одинаковы, роутинг внутри приложения осуществляется по
HTTP_HOST, дело в том, что использовать для роутинга SERVER_NAME, часто
невозможно по ряду причин.

Nginx, конфиг:

server {
 server_name example.com {

   location /private/ {
       internal;
       auth_basic                 "Private ";
       auth_basic_user_file conf/htpasswd;
       ...
   }

    fastcgi_pass 127.0.0.1:9000;
  }
}

server {
 server_name other.com {
  ?
     fastcgi_pass 127.0.0.1:9000;
  }
}

Теперь делаем запрос

GET http://other.com/private/  HTTP/1.1
Host: example.com

Nginx, определяет вирт хост как other.com в котором нет директив для
location /private/ {internal; auth_basic}, но при этом Nginx передает
бекенду HTTP_HOST = example.com, бекенд проверяет HTTP_HOST и отдает контент
для example.com/private/.

Если вы не считаете это багом Nginx, тогда объясните мне, зачем указывать в
location директивы internal; auth_basic, если любой студент сможет их
обойти.

Данная уязвимость открыта для всех бекендов которые для роутинга использует
HTTP_HOST, а как правило это именно так, одна из основных причин, бекенду
нужно работать и в default_server.

Можно конечно сделать на бекенде, мапинг server_name и хостов, всегда на
каждом запросе проверять isset($map[SERVER_NAME][ HTTP_HOST])
Но зачем все это, если в конфиге Nginx и так уже созданы все эти связи и
Nginx на каждом запросе их и так всегда проверяет.
По этому я считаю, что эту уязвимость нужно закрыть на уровне Nginx.

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?21,246086,246301#msg-246301

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