Илья Шипицин 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.
К сожалению это не так.