DNS Rebinding: от внешнего сайта к локальному сервису
Политика одинакового источника (Same-Origin Policy, SOP) десятилетиями воспринималась как "железобетонное" правило: если домен и порт не совпадают, браузер не даст странице свободно общаться с чужими ресурсами. Но в реальном мире у доменного имени есть неприятная особенность - за ним не закреплён навечно один IP-адрес. Именно на этом расхождении между логикой SOP и динамикой DNS строится dns rebinding: техника, которая превращает обычный визит на сайт в мостик к локальным сервисам пользователя.
Мне самому когда-то пришлось много времени проводить в поиске материалов, открывая десятки внешних страниц, часть из которых выглядела сомнительно. Тогда ещё не было привычки смотреть на веб "под микроскопом", но постепенно стало ясно: риск зачастую начинается не с установки файла и не с ввода пароля, а с банального клика по URL. В определённых условиях один заход в браузере способен запустить цепочку запросов к интерфейсу роутера, панели администрирования или локальному API - и всё это без прямого сетевого доступа злоумышленника к внутренней сети.
Суть атаки DNS rebinding проста в формулировке и коварна в реализации: злоумышленник заставляет браузер считать, что он продолжает общаться с тем же самым "сайтом" (тем же доменом), хотя IP-адрес за этим доменом уже подменён на локальный или внутренний. В результате скрипты на странице начинают отправлять запросы туда, куда им обычно ходить нельзя: на 127.0.0.1, 192.168.x.x, 10.x.x.x или в адреса корпоративного периметра.
Подробный разбор того, как именно браузер "переезжает" с внешнего IP на внутренний при неизменном домене, хорошо иллюстрирует атака DNS rebinding и обход SOP на практике - там удобно сверить базовую механику и типовую лабораторную схему.
Как работает механизм "перепривязки"
Классический сценарий выглядит так:
1) Злоумышленник поднимает сайт на домене, которым управляет, и настраивает свой DNS-сервер, чтобы полностью контролировать ответы на запросы к этому доменному имени.
2) Для записи выставляют минимальный TTL - иногда буквально секунды. Это нужно, чтобы кэширование не "зафиксировало" IP и вынудило клиент регулярно переспрашивать DNS.
3) Жертва открывает страницу. Сначала DNS возвращает публичный IP атакующего сервера, браузер загружает HTML и JavaScript.
4) Скрипт начинает делать повторные запросы к тому же домену. Для SOP всё выглядит легитимно: домен-то прежний.
5) Через короткую паузу TTL истекает, браузер делает новый DNS-запрос - и получает уже другой адрес: например, 127.0.0.1 или IP домашнего маршрутизатора. Домен не изменился, а значит в глазах SOP "источник" тот же. Так внешний сайт фактически инициирует обращения к локальному сервису.
В этой точке и рождается dns rebinding exploit: вместо того чтобы атаковать сам периметр сети, злоумышленник использует браузер как "прокси", который уже находится внутри - на компьютере пользователя. Дальше всё упирается в то, насколько доступный внутренний сервис доверчив, есть ли у него защита от CSRF, требуется ли авторизация, и какие методы/эндпоинты он открывает.
Лабораторная демонстрация в контролируемой среде
Чтобы воспроизвести технику безопасно, обычно собирают стенд из двух виртуальных машин: атакующая и "жертва". На стороне атакующего поднимают веб-сервер и DNS-обработчик (часто достаточно простого UDP-сервера на 53 порту), который сначала выдаёт внешний IP, а после нескольких запросов - возвращает localhost или адрес из приватного диапазона.
Практический смысл такого стенда - увидеть, что браузер продолжает обращаться к "тому же домену", но трафик уже уходит в другую сторону. В логах сервиса на 127.0.0.1 в этот момент появляются неожиданные входящие запросы, инициированные страницей из интернета, - именно это и демонстрирует реальную опасность техники.
Почему это всё ещё актуально
Многие внутренние веб-интерфейсы исторически проектировались с логикой "снаружи нас не видно". Это относится к админкам роутеров, панелям управления IoT, локальным агентам, средам разработки, вспомогательным API для десктоп-приложений. Когда такой сервис не требует строгой аутентификации, не проверяет Origin/Host и допускает опасные действия простым GET/POST - атака dns rebinding превращается в практический инструмент, а не академическую демонстрацию.
Отдельная проблема - устройства и приложения, которые слушают только локалхост и считают это достаточной мерой. В реальности "только localhost" не всегда означает "только пользователь": браузер может быть использован как канал доставки запросов, а скрипт - как исполнитель.
Защитные меры: что делать разработчикам и администраторам
Если свести к краткому ответу, то "как защититься от dns rebinding" - это не один переключатель, а набор технических барьеров на разных уровнях:
- Проверяйте заголовок Host и Origin на чувствительных HTTP-эндпоинтах. Если интерфейс предполагается только для локального использования, жёстко ограничьте допустимые значения.
- Включайте аутентификацию везде, где есть управление (даже "домашнее" и "локальное"). Сессии, токены, короткоживущие ключи - всё лучше, чем "пустой вход".
- CSRF-защита и запрет опасных действий через GET снижают вероятность, что скрипт выполнит критичную операцию "в один запрос".
- Привязка админ-интерфейсов к нестандартным портам и отключение лишних методов (PUT/DELETE/небезопасные RPC) уменьшает площадь атаки.
- Сетевые политики: фильтрация обращений к 127.0.0.1/приватным диапазонам на уровне браузера/прокси в корпоративной среде, контроль DNS-ответов, мониторинг аномального TTL.
Эти меры и составляют практическую защиту от dns rebinding: важно не надеяться только на SOP и "невидимость" сервиса, а считать браузер потенциально враждебным посредником.
Кстати, полезно периодически сверять внутренние сервисы с типовыми сценариями, которые описывает защита от DNS rebinding в реальных кейсах: такой взгляд помогает быстро найти классы ошибок - от доверия к Host до отсутствия элементарной авторизации.
Итог
dns rebinding демонстрирует неприятную истину: веб-страница снаружи может дотянуться до внутренних ресурсов не "пробивая" сеть напрямую, а используя поведение DNS и доверие браузера к доменному имени. Поэтому борьба с этим классом атак - это одновременно работа с DNS-политиками, веб-разработкой и настройками внутренних сервисов. Чем раньше локальные интерфейсы перестанут жить по принципу "нас никто не увидит", тем меньше шансов, что один безобидный клик превратится в доступ к приватной инфраструктуре.