#php #ip
#php #ip
Вопрос:
У меня есть веб-сайт, доступ к которому имеют только несколько человек, поэтому количество зарегистрированных IP-адресов очень ограничено. Все, что отправляется зарегистрированными «администраторами», отправляется в определенную папку, зависящую от их IP-адреса. И снова они не могут получить доступ к веб-сайту через прокси или что-либо еще, потому что разрешен ограниченный диапазон IP-адресов.
Могу ли я доверять, $_SERVER['REMOTE_ADDR'] чтобы указать действительный IP, чтобы система регистрации была на 100% стабильной и эффективной?
Комментарии:
1. Я не думаю, что вы можете подделать REMOTE_ADDR без подделки TCP-пакетов, если это вообще возможно. В отличие от многих вещей в
$_SERVER, REMOTE_ADDR не берется из заголовка HTTP-запроса (заголовки HTTP-запроса легко подделать)2. Вы можете подделать TCP-пакеты, но вы не можете подделать полную последовательность подтверждения связи TCP с поддельным IP, за исключением начального пакета SYN. Ответ SYN ACK от сервера отправится в систему с поддельным IP, которая не будет знать, почему этот пакет поступает, и проигнорирует его.
3. @Marc Я не уверен в техническом объяснении, но я видел, как это делается. У меня был IP-блок на экране администратора. Один из нашей технической команды вычислил мой IP (я работал из дома) и обошел его, подделав свой IP-адрес.
4. @Blowski: если у вас есть контроль над маршрутизаторами, вы МОЖЕТЕ подделывать IP-адреса, но это работает только для сетей, которые вы контролируете.
5. @Marc Но как он может выполнить трехходовое подтверждение связи, даже если он отвечал за сети? Ответ от сервера никогда не достигнет его сети, потому что IP-адрес является поддельным. Итак, я все еще думаю, что это невозможно
Ответ №1:
$_SERVER['REMOTE_ADDR'] не может быть изменен пользователем или через HTTP, поэтому вы МОЖЕТЕ доверять ему.
Комментарии:
1. Однако это может быть НЕ реальный IP-адрес пользователя. Прокси, шлюзы NAT и т.д… все они будут скрывать исходный IP-адрес и показывать только IP-адрес последнего обфускационного перехода, с которого пришло соединение. Таким образом, вы не можете использовать его для уникальной идентификации пользователя, поскольку потенциально могут быть сотни или тысячи разных пользователей, проходящих через один и тот же прокси.
2. Отметка верна. Я бы никогда не стал использовать IP-адрес для уникальной идентификации любого пользователя. Поскольку вы сохраняете действия администратора через IP пользователя, если каждый администратор посещает сайт из одной сети, у них, вероятно, будет один и тот же IP-адрес. Вероятно, об этом стоит подумать в вашей архитектуре.
3. С оговоркой, что если веб-сервер (процесс, не машина) скомпрометирован, то http-сервер может быть исправлен для предоставления поддельного адреса. На данном этапе у вас, вероятно, есть более серьезные проблемы, о которых стоит беспокоиться, если только это не атака с очень ограниченным охватом кода http-сервера.
4. Как я уже сказал, я разрешаю доступ определенным пользователям, которых я знаю, разрешая доступ к их IP-адресам. Таким образом, они, если они когда-либо используют прокси, они не могут, потому что IP прокси не разрешен для доступа к веб-сайту (или удаленному администрированию, я бы сказал). И они находятся в разных местах, поэтому IP-адреса разные, и это можно определить, когда я заношу их IP в «белый список». Или, создание определенного имени пользователя и пароля для каждого администратора — лучшее решение?
5. На самом деле это просто зависит от ваших потребностей и того, куда, по вашему мнению, пойдет ваше веб-приложение. Если он внутренний и вы будете вносить в белый список только определенные IP-адреса, то используемый вами метод подходит. Однако, если вы когда-нибудь захотите быть более гибким, я бы разработал решение для аутентификации с использованием базы данных и регистрировал элементы по уникальному идентификатору пользователя.
Ответ №2:
Основное правило заключается в том, что вы не должны доверять подлинности очевидного ip-адреса удаленной машины в тех случаях, когда подделка в сети может вызвать у вас реальные проблемы.
Защищенные системы аутентифицируют не только клиента на сервере, но и сервер на клиенте (для защиты от олицетворения сервера для подделки учетных данных для входа), обычно используя асимметричную криптографию.