пока что все озвученные сценарии для пользователя приведут к 400/404/200, ну то есть "назло маме отморожу уши". ну ок, пользователь специально сконструировал такой запрос, чтобы он попал в другой хост. ему там ответили 400 (в моих случаях обычно 404 в силу особенностей майкрософтовского http.sys)
мне как администратору сервера это чем грозит ? ну увеличится доля 404-х. посмотрю, удивлюсь, разведу руками. надоест, отключу access_log. 18 июня 2014 г., 1:31 пользователь S.A.N <nginx-fo...@nginx.us> написал: > Илья Шипицин Wrote: > ------------------------------------------------------- >> а чем опасен пункт "3)" ? >> мне почему-то кажется, что масштаб бедствия в районе нуля, шум из-за >> ничего. >> >> ну ок, в nginx сработал конфиг для одного значения Host, на бекенд >> улетело другое, что в этом случае может произойти страшного ? >> в интернет-банке деньги спишутся со счета ? >> >> или это какие-то абстрактные угрозы и именно так к ним и надо >> относиться ? > > Угрозы от третьего пункта, зависят от отличий конфигурации хостов, который > исполняет Nginx и который уходит в значении HTTP_HOST на бекенд. > Отличий может быть масса, ограничения по IP, ограничения по кол-ву > одновременных запросов с IP, ограничения по размеру тела запросов и методов > запроса, наличия и отсутствия кеширования, не выполнения директив internal > для location потому что Nginx выполняет директивы другого хоста где нет > таких location и самое забавное это безусловное доверия бекенд-приложения > что юзер прошел аутентификация на уровне веб-сервера потому что эта > аутентификация прописана для хоста который пришел на бекенд в HTTP_HOST. > > Но даже если у вас все хосты сконфигурированы одинаково и вы на сервере > используете SERVER_NAME вместо HTTP_HOST, у вас остается риск что где-то в > конфиге используется переменная $http_host вместо $host, расскажу ситуацию > которая возникла у моих знакомых. > > Все хосты использовали единый fastcgi_cache_path, ключ для файл кеша > создавался как-то так: fastcgi_cache_key "$http_host$uri$args"; > Теперь делаем запрос > > GET http://apple.com/ HTTP/1.1 > Host: samsung.com > > Nginx обрабатывает директивы для хоста apple.com, бекенд правильно > генерирует страницу для apple.com, но в ключ кеша идет значения $http_host > т.е samsung.com и при следующем запросе http://samsung.com/ мы увидим > страницу для apple.com. > Это легко исправляется, в ключ кеша поставить $host вместо $http_host или > для каждого хоста использовать свой собственный fastcgi_cache_path. > > Никогда нельзя доверять значению $http_host, но как показывает практика, > программисты бекенд-приложений доверяют HTTP_HOST, пологая что Nginx > безопасный и не пропустит инвалидный запросы. Но вот не задача разработчики > Nginx так же считают что бекенд разработчики умные и всегда пишут безопасный > код обрабатывая инвалидные заголовки Host. > К сожалению это не так. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,246086,250956#msg-250956 > > _______________________________________________ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru