Как защитить веб-сервер ОТ обратного прокси-сервера - PullRequest
Новая
       16

Как защитить веб-сервер ОТ обратного прокси-сервера

12 голосов
/ 10 октября 2010

У меня есть веб-сайт "www.website.com".

Недавно я узнал , что кто-то установил обратный прокси с почти идентичным URL-адресом "www.website1.com" перед моим веб-сайтом.

Я обеспокоен теми пользователями, которые пришли на мой сайт через этот обратный прокси. Их имя пользователя и пароли могут быть зарегистрированы при входе в систему.

Могу ли я заставить мой веб-сервер отказаться от обратного прокси-сервера?

Например, я настроил обратный прокси-сервер с использованием squid с URL-адресом «www.fakestackoverflow.com» перед «www.stackoverflow.com». Поэтому всякий раз, когда я набираю «www.fakestackoverflow.com» в адресной строке своего веб-браузера, меня перенаправляет на «www.stackoverflow.com» обратный прокси-сервер. Затем я заметил, что URL-адрес в моей адресной строке изменился на «www.stackoverflow.com», что указывает на то, что я больше не прохожу обратный прокси-сервер.

"www.stackoverflow.com", должно быть, обнаружил, что я зашел на веб-сайт с другого URL-адреса, а затем перенаправил меня на веб-сайт через фактический URL-адрес.

Как мне сделать что-то подобное в веб-приложении ASP.NET?

Также запрашивается при сбое сервера .

Ответы [ 9 ]

10 голосов
/ 10 октября 2010

Сначала используйте JavaScript, чтобы прослушать document.location.href и сопоставить его с вашим доменом: 

var MyHostName =  "www.mydomain.com";
if (0 == document.location.href.indexOf("https://")) 
{
    MyHostName = "https://" + MyHostName + "/";
    if (0 != document.location.href.indexOf(MyHostName)) {
        var new_location = document.location.href.replace(/https:\/\/[^\/]+\//, MyHostName);

        if(new_location != document.location.href)
            document.location.replace(new_location);
    }
}
else
{
    MyHostName = "http://" + MyHostName + "/";
    if (0 != document.location.href.indexOf(MyHostName)) {
        var new_location = document.location.href.replace(/http:\/\/[^\/]+\//, MyHostName);

        if(new_location != document.location.href)
            document.location.replace(new_location);
    }
}

Второй : напишите сценарий инициализации для всех ваших страниц ASP, чтобы проверить, соответствует ли IP-адрес удаленного пользователя адресу обратного прокси-сервера. Если он совпадает, перенаправьте на ссылку tinyurl, которая перенаправляет обратно на ваш реальный домен. Используйте tinyurl или другой сервис перенаправления для противодействия перезаписи URL обратного прокси.

Третий : напишите запланированное задание для поиска DNS в поддельном домене и обновите файл конфигурации, который используется вашим сценарием инициализации на шаге 2. Примечание: Не выполняйте поиск DNS в ASP, так как поиск DNS может остановиться на 5 секунд. Это открывает двери для DOS против вашего сайта. Кроме того, не блокируйте только на основе IP-адреса, потому что это легко переместить.

Редактировать : Если вы считаете, что прокси-оператор крадет пароли и имена пользователей, вы должны регистрировать всех пользователей, которым предоставляется IP-адрес прокси-сервера, и отключать их учетные записи. Затем отправьте им электронное письмо с объяснением того, что они стали жертвами фишинг-атаки через доменное имя с ошибкой, и попросите их сменить пароль.

1 голос
/ 19 октября 2010

На мой взгляд, ваша основная проблема заключается в том, что любые меры защиты прикладного уровня, которые вы предприняли для смягчения этой атаки, могут быть обойдены злоумышленником, если предположить, что это действительно вредоносная атака, совершенная компетентным противником.

На мой взгляд, вам определенно следует использовать HTTPS, который в принципе позволил бы пользователю точно подтвердить, обращаются ли они к нужному серверу, но это зависит от того, знает ли пользователь об этом.В настоящее время некоторые браузеры отображают в строке URL дополнительную информацию о том, какому юридическому лицу принадлежит сертификат SSL, что может помочь, поскольку маловероятно, что злоумышленник сможет убедить законный центр сертификации выдать сертификат на ваше имя.

В некоторых других комментариях говорится, что HTTPS может быть перехвачен промежуточными прокси-серверами, что на самом деле неверно.С HTTPS клиент отправляет запрос CONNECT на прокси-сервер, который туннелирует весь будущий трафик напрямую на исходный сервер, не имея возможности прочитать его.Если мы предположим, что этот прокси-сервер полностью настроен и является вредоносным, то он может прервать сеанс SSL и перехватить трафик, но он может сделать это только со своим собственным сертификатом SSL, а не с вашим.Этот сертификат будет либо самоподписанным (в этом случае клиенты получат много предупреждающих сообщений), либо подлинным сертификатом, выданным центром сертификации, в этом случае у него будет неправильное имя юридического лица, и вы сможете вернуться назад.в орган по сертификации, отозвать сертификат и, возможно, попросить полицию принять меры против владельца сертификата, если у вас есть обоснованные подозрения, что они являются фишингом.

Другая вещь, о которой я могу подумать, могла бы смягчитьэта угроза в некоторой степени будет заключаться в реализации функциональности одноразового пароля, либо с использованием аппаратного / программного токена, либо с помощью (моего личного фаворита) SMS-сообщения, отправляемого на телефон пользователя при входе в систему.Не позволяйте злоумышленнику получить доступ к сеансу один раз , но он должен помешать им войти в систему в будущем.Вы можете дополнительно защитить пользователей, потребовав еще один одноразовый пароль, прежде чем позволять им просматривать / редактировать особо важные детали.

1 голос
/ 18 октября 2010

Если вы выполняете аутентификацию по SSL с использованием https://,, в большинстве случаев вы можете обойти прокси.

Также можно найти заголовок X-Forwarded-For во входящем запросе и сопоставить его с подозрительным прокси.

0 голосов
/ 04 сентября 2017

Хорошо, я прошел через аналогичную ситуацию, но мне удалось преодолеть ее, используя другой перенаправленный домен, который постоянно указывает на мой исходный код, а затем проверяя с помощью кода, является ли клиент обратным сервером или нет, если я переадресую его на него.мой второй домен, который перейдет к оригиналу Проверьте больше информации здесь: http://alphablog.xyz/your-website-is-being-mirrored-by-someone-else-without-your-knowledge/

0 голосов
/ 18 октября 2010

Возможно, создайте черный список URL-адресов и сравните запросы с Response.Referer, если веб-сайт находится в этом списке, затем убейте запрос или сделайте свое собственное перенаправление.

Черный список, очевидно, является чем-товам придется обновить вручную.

0 голосов
/ 12 октября 2010

После нескольких дней поисков и экспериментов, я думаю, что нашел объяснение своему вопросу.В моем вопросе я использовал stackoverflow.com в качестве примера, но теперь я собираюсь использовать whatismyipaddress.com в качестве примера, так как оба демонстрируют одинаковое поведение в смысле перезаписи URLplus whatismyipaddress.com может определить мой IP-адрес.

Сначала, чтобы воспроизвести поведение, я посетил whatismyipaddress.com и получил свой IP-адрес,скажем 111.111.111.111 .Затем я посетил www.whatismyipaddress.com (обратите внимание на дополнительный www. в качестве префикса), и URL-адрес в адресной строке моего браузера изменился на whatismyipaddress.com отбрасывая префикс.После прочтения комментариев от Джоша Стодола, я был поражен, чтобы доказать это.

Затем я настроил обратный прокси с URL www.myreverseproxy.com и IP-адресом 222.222..222.222 и я выполнил два приведенных ниже сценария:

  1. У меня есть обратный прокси-сервер к whatismyipaddress.com (без префикса ** www. ).Затем набрал www.myreverseproxy.com в адресной строке моего браузера.Затем обратный прокси-сервер ретранслировал меня на whatismyipaddress.com , и URL в моей адресной строке не изменился (по-прежнему отображается www.myreverseproxy.com ).Далее я подтвердил это, проверив IP-адрес на веб-странице, на которой было указано 222.222.222.222 (это IP-адрес обратного прокси-сервера).Это означает, что я все еще просматриваю веб-страницу через обратный прокси-сервер и не подключен напрямую к whatismyipaddress.com .

  2. Тогда у меня обратный прокси-сервер указывает на www.whatismyipaddress.com (с префиксом wwww. на этот раз).Я посетил www.myreverseproxy.com , и на этот раз URL в моей адресной строке изменился с www.myreverseproxy.com на whatismyipaddress.com .На веб-странице мой IP-адрес показывался как 111.111.111.111 (это реальный IP-адрес моего компьютера).Это означает, что я больше не просматриваю веб-страницу через обратный прокси-сервер и перенаправлен прямо на whatismyipaddress.com .

Я думаю, что это своего рода переписывание URLтрюк, на который указал Джош Стодола.Я думаю, что я собираюсь прочитать больше об этом.Что касается того, как защитить сервер от обратного прокси-сервера, лучше всего использовать SSL.Зашифрованная информация, проходящая через прокси, будет бесполезна, так как ее невозможно прочитать на видном месте, что предотвращает перехват и атаку типа «злоумышленник в середине», что в точности означает обратный прокси.

Хотя защита с использованием javascriptможет показаться тривиальным, поскольку javascript может быть легко удален обратным прокси-сервером, а также препятствует доступу других веб-сервисов, таких как google translate, к вашему веб-сайту.

0 голосов
/ 11 октября 2010

Я пришел с идеей, и я думаю, что решение.

Прежде всего вам не нужно перезаписывать все страницы, потому что таким образом вы блокируете другие прокси и другие службы (например, автоматический перевод Google).

Допустим, вы выиграли , чтобы быть абсолютно уверенным в странице входа в систему .

Итак, что вы делаете, когда пользователь попадает на страницу login.aspx, вы перенаправляете с полным путем вашего сайта снова на login.aspx. 

if(Not all ready redirect on header / or on parametres from url)
  Responce.Redirect("https://www.mysite.com/login.aspx");

Таким образом, я не думаю, что прозрачный прокси может изменить заголовок get и изменить его.

Также вы можете регистрировать любые прокси и / или большие запросы с некоторых ips и проверять его. Когда вы нашли рыболовный сайт , подобный тому, который вы сказали, вы также можете сообщить об этом.

http://www.antiphishing.org/report_phishing.html
https://submit.symantec.com/antifraud/phish.cgi
http://www.google.com/safebrowsing/report_phish/

0 голосов
/ 10 октября 2010

Мало что можно сделать, чтобы предотвратить это, не вызывая сбоя законных прокси (перевод, кеш гугл и т. Д.).Если вам все равно, пользуются ли люди такими услугами, просто настройте веб-приложение на перенаправление, если базовый URL-адрес неверен.

Есть несколько шагов, которые вы можете предпринять, если знаете о прокси и можете узнать их IP-адреса, но это может измениться, и вам придется оставаться на вершине.Ответ @ jmz довольно хорош в этом отношении.

0 голосов
/ 10 октября 2010

Самый простой способ, вероятно, состоит в том, чтобы разместить на своей странице некоторый код Javascript, который проверяет window.location, чтобы увидеть, соответствует ли домен верхнего уровня (TLD) тому, что вы ожидаете, и, если нет, замените его правильным доменом (вызывая браузер для перезагрузки на соответствующий сайт).

...