Одним из преимуществ профессии специалиста по безопасности является работа с многочисленными командами. После аудита специалисты по безопасности получат возможность поработать с администраторами баз данных и аналитиками. Чтобы приложение работало правильно и безопасно, эти команды пытаются устранить уязвимости безопасности, имеющие общую основу. Диалоги между этими командами вызывают некоторые проблемы с реальным IP.
Прокси и реальный IP-концепции
Современные веб-приложения работают на нескольких серверах приложений и системах баз данных. Представьте себе два сервера приложений, использующих один и тот же исходный код. Запросы от пользователя готовы к обработке любым из этих серверов в зависимости от ситуации с нагрузкой. Механизм балансировки нагрузки, который обрабатывает HTTP-запросы перед серверами приложений, решает, какой запрос направить на какой сервер приложений. Это ставит большой вопрос перед системными администраторами промежуточного программного обеспечения и разработчиками программного обеспечения: каков реальный IP-адрес пользователя?
Прокси отвечают за передачу данных между двумя системами. Балансировщик нагрузки — это механизм, отвечающий за работу прокси. Другими словами, только одна система взаимодействует как с пользователем, так и с сервером приложений. Что касается сетевого трафика, веб-серверы A или веб-B всегда взаимодействуют с IP-адресом балансировщика нагрузки. То же самое можно сказать и о пользователях. Для специалистов по безопасности балансировщики нагрузки вызывают серьезные проблемы при атаках с внедрением SQL-кода на основе времени. Но основное внимание здесь уделяется IP-спуфингу.
X-Forwarded-For и IP-отношение
Рассмотрим отношения между X-Forwarded-For, разработчиком и промежуточным ПО. Например, предположим, что задача разработчика приложения состоит в том, чтобы записывать все действия, такие как неправильные попытки ввода пароля пользователями, с их IP-адресами. Сначала разработчик определит IP-адрес пользователя при встрече HTTP-запроса с возможности, предоставляемые языком программирования, который он использует, и постарается продолжать использовать эти данные в приложение.
Поскольку его IP-адрес будет фиксированным на протяжении всего процесса разработки, он всегда будет видеть один и тот же адрес во время тестов, потому что, как правило, пользовательские компьютеры в корпоративные сети работают со статическим IP по MAC-адресу. Устройство проведет некоторые приемочные испытания; однако с этим будут проблемы. Тестовый модуль передаст эту проблему разработчику программного обеспечения.
На этом этапе разработчик может написать контроллер в среде разработки и увидеть передаваемый приложению HTTP-запрос в необработанном виде, так как у всех одинаковый IP-адрес. Это приведет к работе с X-Forwarded-For.
Информация заголовка под названием X-Forwarded-For будет отправлен на сервер приложений. На этом этапе разработчик программного обеспечения увидит свой IP-адрес, который он контролирует с помощью ipconfig, а не балансировщик нагрузки, который он видит в журналах. Многие программисты думают, что могут решить эту проблему с помощью такого блока кода:
функцияполучить IP-адрес() {
$ipKeys = множество(
'HTTP_CLIENT_IP',
'HTTP_X_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_X_CLUSTER_CLIENT_IP',
'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED',
'REMOTE_ADDR'
);
для каждого ($ipKeys как $ ключ) {
если (array_key_exists($key, $_SERVER) истинный) {
для каждого (взорваться(',', $_SERVER[$key]) как $ip) {
$ip = обрезка ($ip);
если (validate_ip($ip)) {
возвращаться $ip;
}
}
}
}
возвращатьсяИссет($_СЕРВЕР['REMOTE_ADDR'])? $_СЕРВЕР['REMOTE_ADDR']: ЛОЖЬ;
}
Этого будет недостаточно — разработчику нужно проверить, является ли входящее значение действительным IP-адресом.
Все вышеперечисленное относилось к той части, которой занимался разработчик. Но для того, чтобы приложение работало правильно и безопасно, команды — работающие вместе в теории, но в реальности, в крайних точках друг от друга — постарайтесь устранить уязвимости безопасности, имеющие общая основа. Теперь попробуйте посмотреть на проблему с точки зрения человека, ответственного за настройку балансировщика нагрузки.
Системные администраторы могут подумать, что разработчики записывают такую информацию, как X-Forwarded-For, потому что данным в HTTP-запросе нельзя доверять. Эти администраторы часто передают X-Forwarded-For; однако они также передают исходный адрес TCP системы, отправившей запрос, в качестве второго значения заголовка. Структура True-Client-IP является хорошим примером этого.
Когда вы сложите все эти вещи вместе, два разных устройства пойдут разными путями для одной и той же проблемы, известной как подмена IP-адреса клиента. В результате возникает критическая проблема, при которой никакая регистрация IP-адресов и авторизация на основе IP не будут работать.
Как обнаруживается спуфинг клиентского IP-адреса в тестах на проникновение?
Большинство тестеров на проникновение используют Firefox для проверки безопасности. Они настраивают Firefox с помощью простого дополнения X-Forwarded-For: 127.0.0.1 для всех HTTP-запросов. А значит, увеличивается возможность обнаружения таких уязвимостей во всех тестах на проникновение. Проведение аудита в соответствии с Контрольный список OWASP гарантирует, что вы проверите наличие таких уязвимостей. Однако для обнаружения уязвимости X-Forwarded-For вам нужен модуль в приложении, который показывает ваш IP-адрес или предпринятые действия.
Как устранить уязвимость X-Forwarded-For
Организациям необходим обязательный документ по разработке безопасных приложений для всех групп разработчиков программного обеспечения и аутсорсинговых компаний. Например, если вам нужен IP-адрес пользователя, компания должна заранее спланировать и установить правило в отношении информации заголовка, которую она будет здесь использовать. В противном случае разные команды будут предлагать разные решения. Если с такой ситуацией нельзя справиться, в игру вступят аутсорсинговые приложения, что затруднит измерение исходных кодов. В целом компании не хотят идти по такому пути.
Но для решения этой проблемы можно использовать следующее правило F5:
когда HTTP_REQUEST {
HTTP:: заголовок удалить X-Forwarded-Для
HTTP:: вставка заголовка X-Forwarded-Для [IP:: удаленный_адрес]
}
Это удаляет поле X-Forwarded-For в HTTP-запросе из внешнего мира. Затем он передает запрос, добавляя к нему IP-адрес системы, отправившей запрос. Таким образом, создается надежный список программного обеспечения, которое действует в соответствии с X-Forwarded-For.
Подводя итог, главная цель здесь — выполнить некоторые проверки HTTP-запросов и создать надежную среду. Блок кода выше является хорошим примером, который вы можете использовать для этого.
Платформы кибербезопасности и документация для предприятий
Единицы, которые кажутся независимыми друг от друга, на самом деле являются частями целого. Поэтому все должно работать системно. Определенные заранее правила должны применяться между каждым юнитом. Если такая рабочая система не будет принята, может возникнуть множество проблем, таких как уязвимость X-Forwarded-For. Для этого следует все продумать заранее и использовать как можно более полную документацию.
И каждое подразделение в этой большой системе должно принять и внедрить основы кибербезопасности. Ваша отправная точка должна состоять в том, чтобы исследовать и изучить логику работы этих фреймворков.