Как запретить третьим лицам прокси-сервер HTTPS?
Я размещаю какой-то интерфейс управления базой данных на https://www.prettylongdomainname.example/ Я реализовал https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security, чтобы запретить людям доступ к этому веб-сайту через HTTP, потому что я не хочу, чтобы мои пользователи передавали свои учетные данные для входа через незашифрованный канал.
Сейчас один пользователь зарегистрировал домен www.pld.example
с провайдером доменных имен, который предлагает своего рода "службу перенаправления доменных имен", которая эффективно выполняет атаку "человек посередине" на мой сайт. Он проксирует исходный веб-сайт и делает его доступным по адресу http://www.pld.example/ некоторые пользователи используют более короткий URL-адрес и не знают, что теперь они отправляют свои пароли в виде простого текста третьей стороне.
Какие механизмы я могу использовать, чтобы предотвратить этот тип атаки MITM?
2 ответа
Вот несколько стратегий, которые вы могли бы рассмотреть:
1. Из журналов вашего сервера выясните, с помощью чего прокси-сервер загружает ваш сайт, и выборочно меняйте ответы для него, например, если он использует одного конкретного поставщика, блокирует или меняет ответы для своего адресного пространства.
2. Может быть вполне достаточно просто неофициально уведомить поставщика прокси-сервера, обязательно связавшись напрямую с его отделом злоупотреблений, а не с продавцами. если IP-адрес их сервера зарегистрирован другой компанией, а не регистратором домена, выберите путь наименьшего сопротивления - сначала обратитесь к поставщику со штаб-квартирой в стране, которая ближе к вашей.
3. В зависимости от ДВУ, будет практически невозможно определить оператора сайта и / или получить постановление суда, которое вынудит их DNS-провайдера отказаться от него.
4. Сообщите о них в Google Safe Browsing. Используйте опцию Report Phishing Page
, Это - если наши повелители Google примут такое решение - создаст большое жирное предупреждение для пользователей прокси и удалит сайт из результатов поиска. Большинство пользователей большинства браузеров используют списки блокировки безопасного просмотра Google, так что это повлияет не на всех, а на близких.
Мы используем комбинацию этих заголовков (config для 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 www.example.com example.com;
Это в сочетании с защитными заголовками остановит большинство атак такого рода.
Однако действительно умный осел может подделать заголовок Host на своем обратном прокси-сервере.
Единственным действительно работающим методом был https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning однако этот стандарт устарел, поскольку он был наполовину приготовлен и довольно опасен для реализации.