Re: Об одной малоизвестной уязвимости в веб сайтах

[Илья Шипицин]

пока что все озвученные сценарии для пользователя приведут к
400/404/200, ну то есть "назло маме отморожу уши".
ну ок, пользователь специально сконструировал такой запрос, чтобы он
попал в другой хост. ему там ответили 400 (в моих случаях обычно 404 в
силу особенностей майкрософтовского http.sys)

мне как администратору сервера это чем грозит ?
ну увеличится доля 404-х. посмотрю, удивлюсь, разведу руками. надоест,
отключу access_log.


18 июня 2014 г., 1:31 пользователь S.A.N <nginx-forum at 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 at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru