Я размещаю какой-то интерфейс управления базой данных на https: //www.prettylongdomainname.example/ Я реализовал Строгая безопасность транспорта HTTP чтобы предотвратить доступ людей к этому веб-сайту по протоколу HTTP, потому что я не хочу, чтобы мои пользователи отправляли свои учетные данные для входа по незашифрованному каналу.
Теперь один пользователь зарегистрировал домен www.pld.example с поставщиком доменного имени, который предлагает некую «службу перенаправления доменного имени», которая эффективно выполняет атаку типа «человек посередине» на мой веб-сайт. Он проксирует исходный веб-сайт и делает его доступным по адресу http: //www.pld.example/ Некоторые пользователи - для удобства - используют более короткий URL-адрес и не знают, что теперь они отправляют свои пароли в виде обычного текста третьим лицам.
Какие механизмы я могу использовать для предотвращения этого типа атаки MITM?
Вот несколько стратегий, которые вы можете рассмотреть:
1. Из журналов вашего сервера выясните, с помощью каких средств прокси загружает ваш сайт, и выборочно измените ответы для него. например если он использует одного конкретного провайдера, заблокируйте или измените ответы для его адресного пространства
2. Может быть вполне достаточно просто неформально уведомить провайдера прокси. обязательно обращайтесь непосредственно к их отделу злоупотреблений, а не к продавцам. Если IP-адрес их сервера зарегистрирован другой компанией, чем регистратор домена, выберите путь наименьшего сопротивления - сначала спросите провайдера, штаб-квартира которого находится в стране, более близкой к вашей.
3. В зависимости от TLD будет от простого до невозможного определить оператора сайта и / или получить постановление суда, вынуждающее их поставщика DNS отказаться от них.
4. Сообщите о них Безопасный просмотр Google Воспользуйтесь опцией Report Phishing Page. Это - если наши повелители Google так решат - создаст большое предупреждение для пользователей прокси-сервера И удалит сайт из результатов поиска. Большинство пользователей большинства браузеров используют списки блокировки безопасного просмотра Google, поэтому это повлияет не на всех, но почти на.
Мы используем комбинацию этих заголовков (конфигурация для nginx):
# Before enabling Strict-Transport-Security headers please read into this topic first.
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
Будьте осторожны, в зависимости от вашего приложения они могут сломать ваш сайт. Прочтите здесь, прежде чем внедрять их https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security
РЕДАКТИРОВАТЬ: как указано, они не будут полностью предотвращать проксирование через внешний домен, вам также следует установить дополнительный шаг обслуживания запросов, которые адресуются только через правильное имя хоста:
Измените ваш nginx.conf по умолчанию на что-то вроде:
server {
listen 443 ssl http2;
server_name _;
### Set dummy certs
ssl on;
ssl_certificate /usr/local/etc/ssl/dummy.crt;
ssl_certificate_key /usr/local/etc/ssl/dummy.key;
ssl_dhparam /usr/local/etc/ssl/dhparam.pem;
### Block all, allow only vhosts on this server
location / {
limit_req zone=one burst=10 nodelay;
deny all;
return 418 "I'm a teapot"; # Just for the fun of it
}
}
### Virtual Hosting
include /usr/local/etc/nginx/conf.d/*.conf;
}
Теперь в /usr/local/etc/nginx/conf.d/ (пути FreeBSD, настройте для вашего дистрибутива) создайте domain_name.conf, который содержит настройки для вашего фактического сайта и установите для него допустимое server_name:
server_name www.example.com example.com;
Это в сочетании с заголовками защиты остановит большинство атак такого рода.
Однако действительно умный болван может подделать заголовок Host и на своем обратном прокси.
Единственный действительно рабочий метод был https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning однако этот стандарт устарел, поскольку он был наполовину готов и довольно опасен для реализации.