Что такое HTTPoxy?
18 июля 2016 года была обнаружена уязвимость приложения CGI, называемая HTTPoxy. Злоумышленник может использовать уязвимые развертывания, передавая заголовок HTTP + Proxy +
со своим запросом, который изменит URL-адрес, используемый приложением при обращении к вспомогательным службам. Это может быть использовано для утечки учетных данных, изменения ответов на приложение и т. Д.
Уязвимость вызвана конфликтом имен между переменной окружения + HTTP_PROXY +
, часто используемой для указания местоположения серверной прокси-службы, и HTTP-заголовком клиента + Proxy +
. Https://tools.ietf.org/html/rfc3875#section-4.1.18[CGI спецификация] вызывает передачу предоставляемых клиентом заголовков в среду с префиксом + HTTP_ +
для пространства имен. Это искажение конфликтует с переменными конфигурации, такими как + HTTP_PROXY +
, которые также начинаются с + HTTP_ +
. Если приложение CGI или библиотека используют эту переменную без дополнительной обработки, она может в конечном итоге использовать значение, предоставленное клиентом при попытке подключения к прокси-службе.
Поскольку эта уязвимость влияет на различные CGI-подобные реализации, был создан ряд идентификаторов уязвимостей безопасности: CVE- 2016-5386, CVE-2016-5386, http: //www.cve.mitre. org / cgi-bin / cvename.cgi? name = CVE-2016-5387 [CVE-2016-5387], http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016 -5388 [CVE-2016-5388], CVE-2016-1000109 и http: // www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1000110[CVE-2016-1000110] (На момент написания статьи они зарезервированы, но не заполнены).
Уязвимость HTTPoxy известна в некоторых формах с 2001 года, но до недавнего времени никогда не признавалась широко распространенной проблемой. Хотя это может повлиять на многие развертывания, смягчение последствий является довольно простым и понятным.
Уязвимые серверы и приложения
HTTPoxy - это общая уязвимость, обнаруживаемая многими реализациями CGI. Приложение или сервер могут правильно реализовать спецификацию CGI и при этом оставаться уязвимыми.
Чтобы развертывание было уязвимым, оно должно:
-
* Используйте переменную окружения
+ HTTP_PROXY +
для настройки прокси-соединений *: либо в самом коде приложения, либо в любых библиотеках, которые используются. Это довольно стандартный метод настройки прокси-серверов с использованием среды. -
* Делать запросы к внутренним службам, используя HTTP *: поскольку конфликт имен связан с префиксом
+ HTTP_ +
, будут затронуты только запросы, сделанные приложением, использующим HTTP. Запросы с использованием HTTPS или любых других протоколов не являются уязвимыми. -
* Работа в CGI или CGI-подобной среде. * Развертывания, в которых заголовки клиентов переводятся в переменные среды с префиксом «+ HTTP_ +», уязвимы. Любая совместимая реализация CGI или связанных протоколов, таких как FastCGI, сделает это.
Как видите, комбинация факторов, связанных с развертыванием и приложением, необходима для уязвимости развертывания. Чтобы проверить, влияет ли ваше развертывание, Luke Rehmann создал простой site для проверки общедоступных сайтов на уязвимость.
Информация о языке
В частности, PHP-приложения должны подвергаться аудиту, поскольку CGI-подобные развертывания гораздо более распространены в экосистеме PHP, чем в других языках. Кроме того, широкое использование метода + getenv +
в популярных библиотеках усугубляет эту проблему, так как не сразу ясно, что это будет возвращать неанизированный пользовательский ввод, а не только переменные конфигурации. Конкретные библиотеки, которые в настоящее время подвержены уязвимости, это Guzzle (версия 4.0.0rc2 и выше), Artax и класс StreamContextBuilder Composer.
Другими языками, которые были признаны уязвимыми при развертывании с использованием CGI, были Python и Go. Эти языки чаще развертываются с использованием других, не уязвимых методов. Однако, если используется CGI, библиотеки, которые наивно читают переменную + HTTP_PROXY +
без изменения своего поведения, уязвимы.
Как победить уязвимость
К счастью, HTTPoxy относительно просто исправить. Уязвимость может быть устранена на уровне веб-сервера или в приложении или библиотеке:
-
Приложения или библиотеки могут игнорировать переменную
+ HTTP_PROXY +
, когда они находятся в среде CGI. -
Приложения или библиотеки могут использовать другую переменную среды для настройки прокси-соединений
-
Веб-серверы или прокси могут отменить заголовок
+ Proxy +
, полученный в клиентских запросах
Если вы используете уязвимую библиотеку, вы должны смягчать угрозу на стороне сервера, пока не появятся исправления для устранения проблемы. Если вы являетесь автором библиотеки или приложения и ваш проект использует переменную + HTTP_PROXY +
для настройки прокси-сервера, рассмотрите возможность использования альтернативной переменной, которая не будет конфликтовать при работе в среде, подобной CGI. Ruby и некоторые другие проекты используют + CGI_HTTP_PROXY +
для этой цели.
Поскольку заголовок + Proxy +
не является стандартным заголовком HTTP, его можно безопасно игнорировать почти во всех случаях. Это можно сделать на веб-сервере или в балансировщике нагрузки, используемом для направления запросов к самому приложению. Поскольку HTTP-заголовок + Proxy +
не имеет какой-либо стандартной законной цели, его почти всегда можно отбросить.
Любой распространенный веб-сервер, балансировщик нагрузки или прокси-сервер могут сбрасывать соответствующие заголовки.
Удаление HTTP-заголовка прокси с помощью Apache
Если вы используете веб-сервер Apache HTTP, модуль + mod_headers +
может использоваться для сброса заголовка для всех запросов.
Серверы Ubuntu и Debian
Чтобы включить + mod_headers +
на серверах Ubuntu или Debian, введите:
sudo a2enmod headers
После этого откройте файл глобальной конфигурации:
sudo nano /etc/apache2/apache2.conf
Внизу добавьте:
файл /etc/apache2/apache2.conf
. . .
RequestHeader unset Proxy early
Сохраните и закройте файл.
Проверьте конфигурацию на наличие синтаксических ошибок:
sudo apache2ctl configtest
Перезапустите службу, если нет сообщений о синтаксических ошибках:
sudo service apache2 restart
Серверы CentOS и Fedora
Модуль + mod_headers +
должен быть включен по умолчанию для обычных установок. Чтобы удалить заголовок + Proxy +
, откройте файл глобальной конфигурации:
sudo nano /etc/httpd/conf/httpd.conf
Внизу добавьте:
/etc/httpd/conf/httpd.conf
. . .
RequestHeader unset Proxy early
Сохраните и закройте файл, когда вы закончите.
Проверьте наличие синтаксических ошибок, набрав:
sudo apachectl configtest
Если нет сообщений о синтаксических ошибках, перезапустите службу, набрав:
sudo service httpd restart
Удаление заголовка прокси HTTP с помощью Nginx
В Nginx смягчение аналогично тривиально. Вы можете легко дезинфицировать среду для любой CGI-подобной среды, работающей на сервере или выше по потоку.
Серверы Ubuntu и Debian
На серверах Ubuntu и Debian параметры FastCGI обычно включаются из файлов + fastcgi_params +
или + fastcgi.conf +
при настройке прокси-сервера FastCGI. Вы можете удалить заголовок + HTTP_PROXY +
в обоих этих файлах:
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_params
Если вы не используете один из файлов при настройке прокси-серверов FastCGI, обязательно включите эту же строку в расположение прокси-сервера:
/etc/nginx/sites-enabled/some_site.conf
. . .
location ~ \.php$ {
. . .
. . .
}
}
Если вы используете Nginx для обычного HTTP-прокси, вы должны также очистить заголовок HTTP + Proxy +
. Заголовки HTTP-прокси устанавливаются в файле + / etc / nginx / proxy_params +
. Вы можете добавить правило, чтобы удалить заголовок + Proxy +
для этого файла, набрав:
echo 'proxy_set_header Proxy "";' | sudo tee -a /etc/nginx/proxy_params
Опять же, если вы не используете этот файл из конфигурации блока вашего сервера, вам придется добавить его в расположение прокси-сервера:
/etc/nginx/sites-enabled/some_site.conf
. . .
location /application/ {
. . .
proxy_pass http://127.0.0.1;
. . .
}
}
Проверьте наличие синтаксических ошибок, набрав:
sudo nginx -t
Если об ошибках не сообщается, перезапустите службу:
sudo service nginx restart
Серверы CentOS и Fedora
Nginx в CentOS и Fedora также использует те же файлы + fastcgi_params +
и + fastcgi.conf +
для настройки прокси FastCGI. Удалите заголовок + HTTP_PROXY +
в обоих этих файлах, набрав:
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_params
Если вы не используете один из этих файлов при настройке прокси-серверов FastCGI, обязательно добавьте эту же строку в само расположение прокси:
/etc/nginx/nginx.conf
. . .
location ~ \.php$ {
. . .
. . .
}
}
Если вы используете Nginx для обычного HTTP-прокси, вы должны также очистить заголовок HTTP + Proxy +
. Вам просто нужно добавить правило для отмены заголовка + Proxy
в любом месте, где вы выполняете` + proxy_pass`. Если вы не уверены, где используется + proxy_pass +
, вы можете легко найти каталог вашей конфигурации:
grep -r "proxy_pass" /etc/nginx
Output/etc/nginx/nginx.conf.default: # proxy_pass http://127.0.0.1;
Любые результаты, которые не закомментированы (как в примере выше), должны быть отредактированы так, чтобы они включали + proxy_set_header Proxy" "; +
:
/etc/nginx/nginx.conf
. . .
location /application/ {
. . .
proxy_pass http://127.0.0.1;
. . .
}
}
Проверьте наличие синтаксических ошибок, набрав:
sudo nginx -t
Если об ошибках не сообщается, перезапустите службу:
sudo service nginx restart
Удаление заголовка прокси HTTP с помощью HAProxy
Если вы используете HAProxy для направления трафика на серверы приложений, вы можете удалить заголовок + Proxy +
перед пересылкой трафика.
Откройте файл + / etc / haproxy / haproxy.cfg +
для редактирования:
sudo nano /etc/haproxy/haproxy.cfg
Вы можете установить директиву + http-request +
в разделах + frontend +
, + backend +
или + listen +
вашей конфигурации.
/etc/haproxy/haproxy.cfg
frontend www
. . .
backend web-backend
. . .
listen appname 0.0.0.0:80
. . .
Их не нужно устанавливать в каждом из разделов, но не мешало бы их включить. Сохраните и закройте файл, когда вы закончите.
Проверьте синтаксис, набрав:
sudo haproxy -c -f /etc/haproxy/haproxy.cfg
Если проблем не обнаружено, перезапустите службу, набрав:
sudo service haproxy restart
Заключение
Уязвимость HTTPoxy давно не используется и может затронуть большой набор приложений, развернутых в Интернете. К счастью, это легко исправить, используя возможности изменения заголовка, свойственные любому веб-серверу.