Доверяя X-Forwarded-For "опознать" посетителю

Question

Сессия Угон

Поэтому у меня есть небольшая проблема. Я пытаюсь определить посетителя, что очень сложно, если не невозможно, с помощью верификаций $ _SERVER, упомянутых в этом вопросе: Preventing session hijacking.

Возможное решение

Чтобы сделать немного сложнее, чем просто копирование куки от клиента A к клиенту B (который, к сожалению, Childsplay), я хочу собрать некоторую информацию и проверить это на что-то я хранится. В моей базе данных я хочу хранить такие вещи, как User-Agent, IP-Address, OS и т. Д. Это я буду шифровать с помощью MCRYPT и хранить. Для сопоставления с пользователем необходимо установить множество переменных, что делает его несколько сложнее, чем просто копирование содержимого cookie для входа в систему.

Проблема

Вот когда начинается моя проблема ... The User-Agent и OS почти, если не полностью идентичны. Причина в том, что это Fat Clients с тем же загрузочным изображением. Другой проблемой является IP. Сервер в Datacenter имеет соединение с офисом. Для наших приложений (даже не доступных извне) IP-адрес для каждого клиента одинаковый. Я узнал, что могу попытаться использовать заголовок X-Forwarded-For, чтобы отличать IP-адреса и, таким образом, сделать пользователя более уникальным.

Что дальше?

Что я хотел бы знать, так это следующее: Как я могу убедиться, что X-Forwarded-For ВСЕГДА устанавливается без каких-либо проблем, к которым имеют доступ клиенты? Что-то нужно добавить туда путем маршрутизации? Наше соединение - https, поэтому я сомневаюсь, что могу просто «впрыснуть» что-то. Кроме того, если я могу добавить что-то подобное, может ли клиентская сторона пользователей сделать это?

клиентов находятся в нашей внутренней сети офиса и приложения (работает в PHP) не доступны из внешнего

Answer 1

X-Forwarded-For и User-Agent HTTP заголовков могут быть легко подделать любой пользователем (так же легко, как копирование файла cookie с одной машины на другую).

На клиенте могут быть использованы расширения Chrome, такие как Header Hacker, и поскольку ваш сайт использует HTTPS, эти заголовки не могут быть добавлены в маршрут (поскольку заголовки должны быть добавлены на прикладной уровень OSI, а не транспортный уровень).

Если вы беспокоитесь о том, что пользователи копируют файлы cookie между собой, существует ли какой-либо механизм, который бы запретил им использовать свои учетные данные для имени пользователя и пароля? Если вам удалось реализовать что-то, что подтвердило бы, что их сеансы остались на одной и той же машине-клиенте, разве они не могли бы просто обойти его, войдя в систему друг с другом?

Помимо моих вопросов, для решения вы можете ввести локальный прокси-сервер в свою внутреннюю сеть, исключительно для подключения к вашему сайту в центре обработки данных. Сайт должен отклонить любые соединения, не входящие в IP прокси-сервера (настройте веб-сервер или брандмауэр, чтобы принимать только IP-адрес клиента прокси-сервера для веб-соединений). Используя этот подход, вам нужно будет установить SSL-сертификат на прокси-сервер, которому может доверять каждый клиентский компьютер. Это позволит прокси-серверу расшифровывать трафик, добавлять соответствующий заголовок IP-адреса (перезаписывать любой набор клиентом), а затем перенаправлять его на ваш сервер.Затем код сервера может безопасно проверять заголовок X-Forwarded-For, чтобы убедиться, что он остается постоянным на сеанс пользователя.

Если это звучит как хорошее решение, прокомментируйте, если у вас есть какие-либо вопросы, и я обновлю свой ответ.

Две другие мысли:

• Вы можете использовать что-то отпечатки пальцев браузер как panopticlick. Однако, поскольку это получение различных значений от клиента и создание отпечатка пальца, все его можно подделать, если заголовки установлены так же, как и у других пользователей. Кроме того, поскольку каждая машина имеет один и тот же загрузочный образ, это может быть одинаковым в любом случае.
• Кулинарные сеансовые файлы cookie: вы можете случайно восстановить сеанс, используя session_regenerate_id(). Это обновит идентификатор сеанса клиента, создающего запрос, и любой другой клиент, использующий один и тот же идентификатор, будет выведен из системы, потому что он отправляет старый идентификатор сеанса. Фактически, вы можете сделать это при каждом запросе, который гарантирует, что только текущий клиент использует текущий сеанс.