Pull to refresh

Comments 17

Да, защита от подмены — более частный случай относительно рассматриваемого.
Смотрите. Допустим, я логинюсь с чужого компьютера. Сервер формирует новый публичный ключ Kpub; шифрует мои сессионные данные на этом ключе и на секретном ключе Кpr (с привязкой к IP, если она включена), записывает две куки — Kpub; Encrypted(Kpub, Kpr, SessionData, IP). Потом я что-то делаю и выхожу.

Что мешает хозяину компьютера увести у меня эти две куки во время работы, дождаться пока я выйду, и передать на сервер их же, выдав себя за меня? Вся информация у него есть, информация о сроке жизни Kpub на сервере вроде как не хранится (иначе при его проверке нужно будет также лезть или в БД или в файл или в какое-то еще хранилище).
Ничего не мешает. Ибо получаем «Запомнить меня» фичу, ограниченную только двойным периодом смены секретного ключа. Кому-то может быть достаточно. Кому нет — смягчим риск введением параметра даты смерти $auth->getStorage()->write() и проверяем ее. Или extends read и write методов своими. Или у нас появился роадмап того класса… Спасибо за комментарий!
По-моему, в простом варианте получаем практически неотключаемую фичу «Запомнить меня».

Т.е. можно еще в SessionData добавить время T — время создания формирования Kpub. При заходе проверять разницу между текущим временем и T при превышении какого-то предела просить перелогиниться. Но это как-то криво.

Да, к сожалению, пока не было времени залезть в код, поэтому все замечания пишу только исходя из общей концепции, а не реализации.
С сессией то же самое — «Запомнить меня» на полчаса или-как-вы-там-настоили-GC-в-ini.
Нет, не криво. Воспроизведя GC публичного ключа сразу в конструкторе, улучшим модель безопасности. Роадмап :)
Разница в том, что в сессию по нажатию пользователем кнопки «выход» вы можете записать соответствующую информацию о том, что пользователь разлогинен. Эта инфа будет храниться на сервере, поэтому злоумышленник, даже уведя сессионную куку, не сможет ей воспользоваться.

А в вашем варианте — эта инфа на сервере не хранится, поэтому кнопка «выход» не сработает.
1. Кнопка выхода вешается на clear() метод. Хочу верить, что обсуждается прочитаный код.
2. Сборщик мусора уже в репозитории.
Теперь уже прочитанный.

Auth_Storage_Cookie->clear() перезапишет куку на клиенте. Но сервер об этом факте забудет после окончания выполнения скрипта. Использованный _publicKey нигде не будет отмечен как «невалдиный».

Поэтому может быть следующая последовательность событий (предположим, что session.gc_maxlifetime — 30 минут) и в конструктор не передали другой $keyLifetime.

23:40 у меня увели куки (скопировали в «безопасное место» $_COOKIE[_k], $_COOKIE[_v]).

23:50 я нажимаю кнопку «выход», сервер стирает $_COOKIE[_k], $_COOKIE[_v] в браузере, в котором я работал (копия, сделанная в 23:40, при этом не стирается, т.к. браузер и тем более сервер понятия не имеет где она находится); я ухожу.

23:55 злоумышленник садится на мое место, выставляет нужные значения $_COOKIE (они у него скопированы в 23:40 и никуда не делись) и отправляет запрос на сервер с этими куками.

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

P.S. И спасибо за coding standarts — читать код удобно.
Все верно. Копирование куки во время логин-сесии и использование их с того же IP в интервале keyLifetime, то есть MITM атака, возможна. MITM вообще рулит.
Да не за что!
Зануда мод он: MITM это слегка другое. Зануда мод офф.

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

Если придумаете, как это обойти — пишите, будет интересно попробовать.
Аналог выхода пользователя в сессиях с помощью очистки ID реализован в методе clear. Аналог выброса пользователя по таймауту в сессиях с помощью GC и регенерации сессии реализован в конструкторе.

Про не-МИТМ из Вики — не согласен. У термина есть чуть другое определение, например, из глоссария книги руководства к экзамену CISA.

Да, этот риск не может быть смягчен самим кодом, серебряных пуль не имеем. К примеру, риск можно перенести в авторизацию. Украл ID и смотришь. А поменять — фиг. Здравствуй, двухфакторка! Кому-то может быть достаточна… Ибо приемлемый уровень защиты информации — это всегда баланс интересов и комплекс мер.

В статье была рассмотрена альтернатива хранения. И благодаря Вам, значительно улучшена. По-моему, тема себя исчерпала.
Если кука зашифрована, что мешает помещать в нее саму lifetime метку?
а она там и есть. как часть SessionData
   try {
            $encryptedContents = $this->_encrypt(
                array(time() + $this->_keyLifetime, $contents)
            );
    } catch (Exception $exception) {
            ...
    }
    ...
    $_COOKIE[$this->_valueCookieName] = $encryptedContents;
Sign up to leave a comment.

Articles