On 09.01.2014 21:03, S.A.N wrote:

> Вот наглядный пример:
> fastcgi_param HTTP_HOST1 $http_host;
> fastcgi_param HTTP_HOST2 $host;
> fastcgi_param HTTP_HOST3 $server_name;
>
> Делаем, запрос
> GET http://site3.dev/ HTTP/1.1
> Host:~%#$^&*()<>?@\!."'{}[]=+|
>
> На выходе получим
> _SERVER["HTTP_HOST1"]: ~%#$^&*()<>?@\!."'{}[]=+|
> _SERVER["HTTP_HOST2"]: site3.dev
> _SERVER["HTTP_HOST3"]: site2.dev
>
> Кому интересно почитать, подробней вот ссылка.
> http://habrahabr.ru/post/166855/
>
> Как видите, корректное значения имеют только переменные $host и
> $server_name, все что основывается на $http_host имеет потенциал уязвимость,
> если бекенд доверяет этой переменой, лично я знаю несколько популярных РНР
> фрейморков которые используют эту переменную без проверки и без
> экранирования в SQL запросах.

и пофиксить эту проблему можно в исходниках nginx таким образом,
что если вдруг в переменных $host и $http_host оказываются разные
значения, чтобы nginx в $http_host записывал значение из $host.

тогда после установки следующего обновления nginx эта уязвимость
в backend`ах автоматически пофиксится у всех пользователей nginx.

причем без какой-либо необходимости пользователям править
файлы fastcgi.conf / fastcgi_params и все производные от них.

--
Best regards,
Gena

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