Re: proxy cache key и fastcgi cache key
S.A.N
nginx-forum at nginx.us
Mon Jan 13 05:31:19 UTC 2014
Для убедительности, приведу ещё такой пример.
Есть бекенд приложения, которое обслуживает множество хостов, всех этих
хостах 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