Безопасность входа: могу ли я доверять php's $ _SERVER ['REMOTE_ADDR']?

Question

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

1. По безопасному соединению договоритесь о случайном токене T. Это хранится в куки.
2. Сервер хранит f(T)=hash(private_salt,T,username,password,$_SERVER['REMOTE_ADDR'])
3. T предоставляется позже по незашифрованным соединениям. Сервер повторно вычисляет f(T) для проверки подлинности соединения.

Идея состоит в том, что T не представляет никакой конкретной информации, и даже если она будет украдена, соединение с другим исходным IP-адресом приведет к вычислению другого f(T).

Очевидная слабость - кража сеанса за NAT. Допустим, мы можем отклонить это на практике. Вопрос сводится к следующему: насколько легко подделать соединение, сохранив $_SERVER['REMOTE_ADDR']?

Этот сайт требует только умеренной безопасности. Там не будет чувствительного трафика. Модель угрозы в основном справляется с вандализмом. Мне нужно только сдерживать скучающих людей, а не русскую мафию. Учитывая это предположение, является ли вышеуказанный протокол достаточно безопасным?

Также давайте предположим, что это происходит с обычным веб-браузером и LAMP - для безопасной передачи пароля, https - единственная игра в городе? Похоже, что достаточно обмена ключами Диффи-Хеллмана или аналогичного (подражание серверу не входит в модель угроз) и не требует всей этой подписи. Существует ли для этого стандартный модуль apache / php, который поддерживается большинством браузеров?

Answer 1

Плохая идея.

Раньше я был в большой сети с несколькими IP-адресами.Каждый запрос, который я делал, был назначен на один из IP-адресов балансировщиком нагрузки.Фактически это означало, что мой IP-адрес редко был одинаковым в двух последовательных запросах.Я буду выходить из вашей системы каждый раз, когда загружаю страницу.

Вы можете попробовать использовать $_SERVER['HTTP_USER_AGENT'], так как для этого потребуется, чтобы у вора cookie был точно такой же браузер или (при условии, что модель угрозы позволяетдля достаточно опытных вандалов) подделать точно такую ​​же строку UA.Тем не менее, если вы никому не говорите, что проверяете строку UA, для неопытных хакеров может быть непонятно, что ваш сервер отвергает по поводу «совершенно хорошего» сеансового cookie.

Answer 2

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

Итак, особенно в зависимости от используемой модели угрозы, выполнитене работает подмена IP-адресов;для соединений TCP это очень сложно осуществить на практике.Поскольку клиенты могут изменять IP-адреса (динамические IP-адреса, выдаваемые интернет-провайдерами, прокси-серверы с балансировкой нагрузки, NAT / PAT и т. Д.), Вы с большей вероятностью ошибочно отклоняете хороших пользователей, чем правильно отклоняете плохих, используя этот подход.Сгенерируйте хороший идентификатор сеанса, сохраните его в файле cookie и проверяйте его при каждом запросе.

Answer 3

кажется, что это не сработает, если: Кто-то крадет и IP-адрес, и cookie-файл вошедшего в систему пользователя, или кто-то знает пароль пользователя / пароль.... я не понимаю, как это будет справляться с любым типом вандализма (за исключением, может быть, cookie-bruteforce / атак с отгадыванием): /

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