Защита файлов cookie и сеансов - PullRequest
10 голосов
/ 19 декабря 2011

Проблема, с которой я сталкиваюсь и которая не может быть решена, заключается в следующем:

У меня есть клиент, представляющий собой крупную организацию из 1500+ пользователей в 7-8 разных местах. Приложение представляет собой PHP-приложение, созданное на основе Kohana v3.0. Организация находится за прокси-сервером фильтрации на уровне интернет-провайдера. Каждое местоположение имеет один основной публичный IP-адрес, который направляется через прокси-сервер, а затем в Интернет. Каждый пользователь имеет рабочую станцию ​​Mac или Windows, выданную работодателем.

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

Из-за настройки сети сервер видит, как сотни пользователей входят в систему с одного IP-адреса с помощью одного и того же агента пользователя. Сначала я думал, что способ создания файлов cookie, уникальных для браузера (пользовательского агента), в Kohana v3 недостаточно уникален для этого реального приложения.

Кто-нибудь когда-либо испытывал что-то подобное? И какие действия следует предпринять при создании файлов cookie и сеансов? Будет ли лучше управлять файлами cookie и активными сеансами в базе данных?

  • Модули Kohana: Jelly-Auth, Jelly и Auth

  • Сервер: Apache / 2.2.9 (Debian) mod_fastcgi / 2.4.6 mod_jk / 1.2.26 PHP / 5.2.6-1 + lenny8 с Suhosin-Patch mod_ssl / 2.2.9 OpenSSL / 0.9.8g

  • Известные браузеры: IE 8 и 9, Firefox (ОС и Win) и Safari (ОС)

Ответы [ 3 ]

2 голосов
/ 19 декабря 2011

Это просто идея, но есть (в зависимости от вашей версии Debian и PHP) ошибка с сессиями PHP. Что я предлагаю вам попробовать:

  1. Проверьте эту ссылку - это может быть не связано с вашей проблемой, но стоит попробовать
  2. Переключиться на драйвер базы данных - я бы дал 90% шанса, что это все исправит
  3. Тестирование на сервере отличном от сервера Debian - это может быть нелегко выполнить, хотя
2 голосов
/ 19 декабря 2011

Ничего себе, это ужасная уязвимость, хороший улов!

На сегодняшний день лучший способ генерировать куки в PHP - это позволить PHP сделать это: session_start().И это все!Если вы создаете свой собственный файл cookie, то вы действительно где-то напутали.Теперь вы можете использовать $_SESSION[] super global.Лучше всего вызывать session_start() в общем заголовочном файле, прежде чем вы получите доступ к $ _SESSION в вашем приложении.

Вероятно, следует учитывать и другие проблемы, такие как owasp a9 , csrf и флаги cookie: HTTP_Only и флаг "secure" (принудительное использование cookie через https).).

0 голосов
/ 28 декабря 2011

Я не уверен, правильно ли я вас понял, но ... Я понял, что запрос выглядит так:

user (рабочая станция) ==> proxy () ==> internet ==> companyвеб-сайт (и ответ в обратном направлении).

Проверьте, не устанавливает ли прокси-сервер «HTTP_X_FORWARDED_FOR» (в суперглобальной переменной $ _SERVER).Это может быть единственным способом определения IP-адреса рабочей станции пользователя.Если так, то все готово.

...