Как запретить третьим лицам прокси-сервер 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 однако этот стандарт устарел, поскольку он был наполовину приготовлен и довольно опасен для реализации.

Другие вопросы по тегам