Разберите проверку: приложение ограничивает административный раздел по IP, получая адрес клиента из HTTP-заголовка. Как установить, можно ли обойти это ограничение подменой заголовка?
Нужно отправить один и тот же запрос с разными значениями заголовка, содержащего адрес клиента, и сравнить результат с запросом без этого заголовка. Если доступ появляется только из-за значения, которое может задать сам клиент, приложение уязвимо: заголовок используется как доверенный источник для решения об авторизации.
Безопасная реализация принимает адрес клиента только от конкретного доверенного прокси, а сам прокси удаляет входной заголовок от внешнего клиента и формирует новый. Проверка должна также учитывать возможность прямого доступа к приложению в обход этого прокси.
Заголовки с адресом исходного клиента появились из-за обратных прокси, балансировщиков и шлюзов: после их внедрения приложение видит сетевым источником запроса адрес промежуточного узла, а не реального клиента. Передача исходного адреса позволила сохранять корректные журналы, применять ограничения частоты и выполнять сетевые политики на уровне приложения.
Проблема возникла потому, что такой заголовок является обычными данными HTTP и сам по себе не доказывает, кто его установил. Доверие к нему допустимо только при известной цепочке прокси и контролируемом сетевом маршруте.
Административные функции иногда разрешают доступ по списку IP-адресов, считая такие запросы внутренними. Если приложение безусловно принимает адрес из клиентского заголовка, внешний пользователь может указать разрешённый адрес и получить доступ без прохождения настоящего сетевого ограничения.
Последствия зависят от защищённой функции: это может быть просмотр служебных данных, изменение настроек, управление пользователями или выполнение административных операций. Даже если основной вход требует аутентификации, такая ошибка может стать дополнительным способом обойти отдельный контур защиты.
Сначала нужно определить архитектуру: есть ли перед приложением балансировщик или обратный прокси, какие узлы имеют право передавать исходный адрес, доступен ли сервер приложения напрямую, какое звено принимает решение о доступе. Проверять следует не только один предполагаемый заголовок, но и фактический контракт между прокси и приложением.
Затем выполняют серию сравнительных запросов к одной защищённой функции: без заголовка, с разрешённым адресом, с запрещённым адресом, с несколькими адресами и с некорректными значениями. Если результат меняется в пользу доступа при простом добавлении или изменении заголовка со стороны клиента, это свидетельствует о подменяемом источнике доверия.
Важно проверить разные пути доставки. Запрос через штатный прокси может быть защищён корректно, тогда как прямое обращение к внутреннему адресу приложения позволяет самостоятельно установить тот же заголовок. Также нужно проверить неоднозначные случаи: список адресов, пробелы, IPv4 и IPv6, альтернативные представления адреса, повторяющиеся заголовки и различия между компонентами цепочки.
Корректная модель такова: приложение доверяет заголовку только когда запрос пришёл от конкретного прокси из разрешённого диапазона; прокси очищает внешний вариант и устанавливает собственное значение; прямой доступ к приложению закрыт сетевыми правилами. Если сетевой источник нельзя надёжно подтвердить, IP-адрес не следует использовать как единственный фактор авторизации.
Компромисс состоит в том, что строгая привязка к инфраструктуре требует согласованной настройки при масштабировании и смене прокси. Однако отказ от такой проверки ради удобства превращает сетевое ограничение в контролируемое клиентом поле. Для критичных операций предпочтительнее сочетать сетевые ограничения с аутентификацией, авторизацией и журналированием.
Внутренний раздел был доступен только из корпоративной сети. Через публичный балансировщик приложение получало адрес пользователя из заголовка, а тестовый прямой маршрут к узлу приложения оставался доступным из той же сети балансировщиков. Запрос с подменённым разрешённым адресом через публичный вход не дал доступа, но тот же запрос через прямой маршрут прошёл.
Рассматривались три варианта. Первый — доверять заголовку от любого источника: это проще, но полностью небезопасно. Второй — отказаться от IP-ограничения: он устраняет ошибочное доверие, но снижает дополнительный барьер. Третий — закрыть прямой маршрут, разрешить приложению доверять заголовку только от балансировщика и оставить обязательную проверку учётной записи: он требует изменений инфраструктуры, зато сохраняет назначение ограничения.
Выбрали третий вариант. После исправления прямой маршрут стал недоступен, внешний заголовок отбрасывался балансировщиком, а приложение учитывало только значение, полученное от доверенного узла. Повторная проверка показала, что подмена заголовка, добавление нескольких значений и обращение в обход балансировщика больше не дают административного доступа.
Нет. Нужно проверять все доверенные и недоверенные пути до приложения. Публичный прокси может корректно очищать заголовок, но другой шлюз, внутренний балансировщик или прямой адрес сервера может передавать его иначе. Без проверки маршрутов тест не подтверждает, что доверенная граница действительно едина.
Нельзя делать такой вывод без документированного правила конкретной инфраструктуры. Цепочка может содержать несколько прокси, а клиент способен добавить собственное значение в начало или конец. Приложение должно знать, сколько правых элементов добавляют доверенные прокси, и принимать их только при подтверждённом источнике запроса; механическое чтение первого адреса небезопасно.
Не всегда. Даже корректная обработка адреса не защищает от ошибок диапазонов, неверной маски, IPv6-несоответствий или компрометации доверенного прокси. Кроме того, IP — нестабильный признак пользователя: за одним адресом могут находиться многие люди, а адрес может измениться. Поэтому для чувствительных действий IP-ограничение следует рассматривать как дополнительный слой, а не замену аутентификации и серверной авторизации.