HTTPoxy: Угроза безопасности CGI-приложений

Бесчисленные веб-проекты полагаются на прокси-серверы в целях производительности и безопасности. Эти практичные программы функционируют как коммуникационный интерфейс между клиентом и веб-сайтом и разгружают веб-сервер, принимая, редактируя, маршрутизируя и отвечая на HTTP-запросы. Но из-за уязвимости в системе безопасности, известной как HTTPoxy, эта техника может быть использована злоумышленниками для кражи данных. Под удар попадают приложения, основанные на стандарте CGI (Common Gateway Interface) и конфигурирующие так называемые переменные среды. Например, некоторые программы могут считывать конфигурацию прокси из переменных, что быстро превращается в проблему, когда злоумышленники манипулируют этими настройками.

Что такое HTTPoxy?

Когда веб-сервер взаимодействует с клиентом пользователя через Common Gateway Interface, стандарт RFC 3875 предусматривает, что заголовки всех отправленных HTTP-запросов хранятся как переменные среды. Имя этой переменной состоит из префикса «HTTP_» и имени заголовка в верхнем регистре. В данном случае заголовком является «Proxy», что автоматически генерирует переменную HTTP_PROXY. Это задается как конфигурация настроек прокси по умолчанию. Если CGI-приложение достигает или выполняет запрос, содержащий HTTP_PROXY, оно перенаправляется через соответствующий прокси-сервер.

Описанные обстоятельства позволяют злоумышленнику ввести в игру собственный прокси-сервер и использовать его для завладения конфиденциальной информацией. Для этого он отправляет HTTP-запрос с заголовком Proxy и соответствующим значением (например, IP-адрес прокси-сервера), чтобы последующие запросы пользователей — входящие или исходящие — перенаправлялись на него. В зависимости от выбранного сценария, злоумышленник может либо вернуть свои собственные данные по своему усмотрению, либо напрямую прочитать введенные пользователем данные.

Неизбежная уязвимость в системе безопасности?

Уязвимость, название которой не имеет особого смысла, была впервые обнаружена в марте 2001 года. Программист Рэндал Л. Шварц обнаружил HTTPoxy в Perl-библиотеке libwww-perl и сообщил об этом разработчику библиотеки Гисле Аасу. Уязвимость была немедленно закрыта в обновлении 5.51 путем изменения имени переменной, через которую можно было управлять конфигурацией прокси, на CGI_HTTP_PROXY. В том же году уязвимость была обнаружена и в программе передачи данных curl, и разработчик Даниэль Стенберг адаптировал программу таким образом, что только строчный вариант http_proxy мог определять прокси-сервер — в то же время предупредив, что для систем Microsoft этого принципиально недостаточно. В современных версиях Windows эта проблема больше не существует.

Примерно десять лет спустя, в июле 2012 года, команда Ruby столкнулась с давно забытой проблемой HTTPoxy при реализации класса NET::HTTP, клиентского HTTP API для приложений Ruby. Чтобы обойти проблему, они установили HTTP_PROXY и другие под статус стандартной переменной. В последующие годы веб-серверные приложения NGINX (2013) и Apache (2015) стали одними из самых заметных случаев, когда внимательные пользователи сообщили разработчикам о потенциальной опасности.

В 2016 году команда безопасности компании-разработчика Vend обнаружила, что брешь в безопасности HTTPoxy все еще существует спустя 15 лет после ее первого обнаружения, и PHP, помимо различных других языков программирования, а также библиотек, может быть использован — при условии, что они используются в сочетании с CGI или аналогичной средой выполнения с переменными. Многие затронутые приложения, позволяющие использовать HTTPoxy, были внесены в официальные спецификации уязвимостей безопасности, известные как CVEs (Common Vulnerabilities and Exposures):

  • CVE-2016-5385: PHP
  • CVE-2016-5386: Go CVE-2016-5387: Apache HTTP Server
  • CVE-2016-5388: Apache Tomcat
  • CVE-2016-6286: spiffy-cgi-handlers для CHICKEN
  • CVE-2016-6287: http-клиент CHICKEN
  • CVE-2016-1000104: mod_fcgi
  • CVE-2016-1000105: cgi скрипт Nginx
  • CVE-2016-1000107: Erlang inets
  • CVE-2016-1000108: YAWS
  • CVE-2016-1000109: HHVM FastCGI
  • CVE-2016-1000110: Python CGIHandler
  • CVE-2016-1000111: Python Twisted
  • CVE-2016-1000212: lighttpd

Защитите себя и свой сервер от HTTPoxy

Независимо от того, используете ли вы собственный веб-сервер или нет, HTTPoxy представляет опасность, когда вы находитесь в Интернете. Если запрашиваемый веб-сервис может быть перенаправлен через нежелательные внешние HTTP-запросы, то, как следствие, его данные не будут в надежных руках. Чтобы минимизировать риск потери данных, следует отдавать предпочтение сайтам, которые защищены сертификатом TLS/SSL и передают всю информацию в зашифрованном виде. Таким образом, перенаправить данные через ложный прокси-сервер все равно возможно, но вероятность того, что преступники воспользуются защищенной информацией, гораздо ниже, а в лучшем случае они вообще не получат никакой выгоды. Если у вас есть собственный сайт, переход на HTTPS является обязательным уже сегодня.

У вас всегда есть возможность избежать HTTPoxy в целом, просто устранив уязвимость. Поскольку прокси-заголовок не зарегистрирован ни как стандарт IETF, ни как официальный заголовок IANA, вы можете безопасно перехватить его до того, как он достигнет вашего веб-приложения. По умолчанию стандартные клиенты и серверы HTTP не отправляют никаких пакетов данных с этим заголовком. В дополнение к шифрованию обмена данными HTTP, у вас есть два разных способа не допустить опасные запросы к вашему веб-проекту:

  1. Отфильтровать прокси-заголовок из всех входящих пакетов.
  2. Автоматически блокировать все входящие пакеты, содержащие прокси-заголовок.

Первый вариант гораздо более распространен, и его можно осуществить с помощью любого обычного веб-сервера, прокси-сервера или программного обеспечения для балансировки нагрузки. В следующих разделах вы найдете информацию о том, как убрать потенциально опасные заголовки из трафика данных на различных дистрибутивах Linux с помощью приложений веб-серверов Apache и NGINX, а также программы прокси-сервера HAProxy.

Избегайте HTTPoxy с помощью Apache

Свободное программное обеспечение Apache установлено по умолчанию во всех распространенных дистрибутивах Linux и до сих пор является лучшим выбором для многих, когда речь заходит о работе собственного веб-сервера. Одной из особенностей этой программы, среди прочих, является модуль mod_headers, который позволяет отфильтровывать заголовок proxy из всех входящих HTTP-запросов. Стратегия немного отличается в зависимости от дистрибутива.

Ubuntu и Debian:

Первым шагом является активация модуля, которая выполняется с помощью следующей команды:

sudo a2enmod headers

Затем откройте центральный конфигурационный файл Apache с помощью редактора, для чего рекомендуется использовать инструмент командной строки nano (использованный в примере):

sudo nano /etc/apache2/apache2.conf

Теперь расширьте этот файл в конце следующей записью:

<IfModule mod_headers.c>
  RequestHeader unset Proxy early
</IfModule>

После сохранения файла активируйте защиту HTTPoxy, загрузив указанный конфигурационный файл через скрипт a2enconf и перезапустив сервер:

sudo a2enconf httpoxy
sudo service apache2 restart

CentOS и Fedora:

Если вы используете версии дистрибутивов Linux CentOS или Fedora, то модуль mod_headers уже активирован по умолчанию, поэтому вы можете пропустить этот шаг и сразу перейти к открытию конфигурационного файла:

sudo nano /etc/httpd/conf/httpd.conf

Вставьте новую запись в конец:

RequestHeader unset Proxy early

Затем сохраните изменения и перезапустите сервер Apache:

sudo service httpd restart

Удаление прокси-заголовка HTTP с помощью NGINX

Как приложение для веб-сервера, NGINX в настоящее время является признанной силой, популярность которой растет. С помощью программного обеспечения с открытым исходным кодом требуется всего несколько шагов, чтобы защитить CGI-приложения, работающие на сервере или между клиентом и сервером, от бреши в безопасности HTTPoxy.

Ubuntu и Debian:

Параметры FastCGI (FastCGI — это оптимизация стандартов CGI) под Ubuntu и Debian обычно содержатся в файлах fastcgi_params или fastcgi.conf, если вы установили прокси NGINX FastCGI. В обоих файлах вы можете отсечь заголовок прокси в HTTP-запросах. Просто используйте следующие строки кода:

echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_params

Если вы используете NGINX в качестве обычного HTTP-прокси, вы также можете отфильтровать этот заголовок. Для этого введите соответствующее правило в файл proxy_params, в котором перечислены параметры для прокси-сервера:

echo 'proxy_set_header Proxy "";' | sudo tee -a /etc/nginx/proxy_params

В последней строке перезапустите NGINX командой:

sudo service nginx restart

CentOS и Fedora:

Стратегия запрета HTTPoxy опасностей для FastCGI прокси на CentOS или Fedora не сильно отличается от стратегий для систем Ubuntu и Debian. Поскольку конфигурации NGINX в этих дистрибутивах задаются в файлах fastcgi_params или fastcgi.conf, вы также можете отключить заголовок прокси здесь с помощью команд, перечисленных ранее:

echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_params

Чтобы защитить обычные прокси под Fedora и CentOS, нужно убедиться, что заголовок блокируется везде, где NGINX использует директиву proxy_pass. Чтобы выяснить, где они используются, можно воспользоваться услугами команды поиска grep:

sudo grep -r "proxy_pass" /etc/nginx

Она содержит список текстовых файлов с директивой, где выходные данные выглядят примерно так, как показано в следующем примере:

/etc/nginx/nginx.conf.default:        #    proxy_pass http://127.0.0.1;

В этом случае proxy_pass будет находиться в конфигурационном файле NFINX. Соответствующая запись в nginx.conf должна быть добавлена следующим образом:

proxy_pass http://127.0.0.1;
proxy_set_header Proxy "";

В обоих случаях вы завершаете работу перезапуском сервера:

sudo service nginx restart

Защитите свой HAProxy сервер от HTTPoxy

Если вы направляете HTTP-запросы к вашему веб-проекту через HAProxy-сервер, вы можете удалить заголовок прокси еще до того, как прокси отправит запросы. Метод не отличается в различных дистрибутивах Linux. Сначала откройте центральные конфигурационные файлы прокси-приложения с помощью следующей команды:

sudo nano /etc/haproxy/haproxy.cfg

Теперь откройте файл haproxy.cfg с помощью того же редактора командной строки nano, что и ранее. Если вы указали альтернативный каталог для HAProxy во время установки, то вам нужно соответствующим образом изменить команду.

В открывшемся файле теперь можно вставить директиву HTTP запроса, чтобы удалить нежелательный заголовок в трех секциях «frontend», «backend» и «listen». Результат выглядит следующим образом:

frontend name
  http-request del-header Proxy
…

backend name
  http-request del-header Proxy
…

listen name
  http-request del-header Proxy

Сохраните изменения и перезапустите службу HAProxy:

sudo service haproxy restart

Проверка безопасности с помощью HTTPOXY Vulnerability Checking Tool

После того как вы сохранили конфигурацию прокси против HTTPoxy с помощью перечисленных ранее возможностей защиты, необходимо проверить, все ли ведет себя так, как предписано. Для этого существуют такие приложения, как HTTPOXY Vulnerability Checking Tool от Luke Rehmann. Этот бесплатный и полезный веб-сервис проверяет URL на уязвимость HTTPoxy, отправляя HTTP-запрос с прокси-заголовками на URL, который перенаправляет на альтернативный сервер. Если инструмент не получает ответа от сервера, значит, заголовок был успешно заблокирован.

Чтобы воспользоваться сервисом, просто введите URL веб-приложения, которое вы хотите проверить, в поле ввода и нажмите кнопку «Test».

Оцените статью
cdelat.ru
Добавить комментарий