Повышает ли безопасность идентификатора сеанса?

(я думаю) Я понимаю, почему идентификаторы сеансов должны вращаться при входе пользователя в систему - это один важный шаг для предотвращения session fixation.Повышает ли безопасность идентификатора сеанса?

Однако существует ли какое-либо преимущество для случайного/периодического вращения идентификаторов сеансов?

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

источник

2010-05-17 David Underhill

Если вы используете идентификаторы сеансов, хранящиеся в файлах cookie, фиксация сеанса не является проблемой. Я просматривал документ, который вы вставили, и я вижу такие вещи, как использование DNS и XSS для владения пользователем, что, очевидно, намного выше (не говоря уже о раздельных) проблемах, чем фиксация сеанса. Если у вас есть идентификатор сеанса (с приемлемым уровнем энтропии), хранящийся в файле cookie, нет разумной причины повернуть его. Единственная причина повернуть его - это потому, что она угадана или уязвима каким-то другим способом, и в этом случае пользователь все равно будет владеть.

источник

2010-05-17 03:34:24

Я думаю, что поворот идентификатора сеанса (SID) при входе в систему необходим, даже если он хранится в файле cookie. Рассмотрим это: злоумышленник просматривает веб-сайт на общем компьютере и получает назначенный SID (но не входит в систему). Затем атакующий уходит. Если следующий пользователь затем войдет в систему и SID не будет повернут, злоумышленник знает SID и может использовать его для маскировки как пользователь, который вошел в систему. * Этот сценарий немного надуманный * (надеюсь, что общий компьютер все еще имеет отдельные учетные записи), * но возможно *. –

То, что вы сказали, является серьезной уязвимостью (думаю, киоски). Я предполагал, что сайт назначает новый идентификатор сеанса при входе в систему. Конечно, вы должны назначить новый идентификатор сеанса при входе в систему. И нет, эта атака вовсе не надуманна. –

Согласовано. (примечание: мой комментарий был главным образом в ответ на первое предложение в вашем ответе) –

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

источник

2010-05-17 03:07:41

Это было бы возможно, если бы идентификаторы сеанса были созданы последовательно. Однако хорошие генераторы идентификаторов сеансов генерируют случайные идентификаторы именно по этой причине - так что злоумышленники не могут их угадать. –

Звучит как глупая идея в целом.

Это полностью испортило бы пользователей, если они нажмут кнопку «Назад», поскольку ссылки на предыдущей странице теперь будут содержать устаревший идентификатор сеанса. Вы также можете выкинуть любой AJAX, потому что каждый раз, когда RPC создается на сервере, все ссылки/формы на странице требуют обновления, так как теперь они имеют недопустимые значения. Если что-то менее безопасно, потому что это означает, что ваше приложение становится более сложным и дает больше шансов на ошибку.

Если аргументация требует, чтобы вы «вращали» идентификаторы, это, вероятно, означает, что ваши идентификаторы плохо сгенерированы, и это должно быть исправлено. Если snooping является проблемой, используйте SSL.

источник

2010-05-17 03:07:56

Я не думаю, что это создает проблему с кнопкой «Назад». И я думаю, что вы можете обойти AJAX/почти одновременные запросы, только поворачивая идентификатор сеанса каждый N запросов и сохраняя старые на короткий период. Конечно, только потому, что он не винит эти вещи, это не значит, что это хорошая идея. Я согласен с вами в том, что я не думаю, что периодическая ротация идентификатора сеанса тоже стоит того. Я также согласен с тем, что если snooping является проблемой, тогда SSL является обязательным. –

Не вращая/не изменяя, вы фактически прекратили вращение. Так что, если ваше приложение является одной страницей и никогда не изменяется. Ваш аякс на этой странице в конечном итоге станет старше, чем TLD идентификатора сеанса. –

Плохая идея сохранить sessionID в URL-адресах в любом случае. Поэтому, если sessionID упорядоченно хранится в файле cookie, кнопки back/forward в SPA не будут терпеть неудачу. – SteAp

В соответствии с этим сообщением SSL Labs (с 2013 года), чипы RC4 (все еще видны в дикой природе, 2017) слабы, и может позволить черной шляпе выставлять данные cookie сеанса из перехваченного HTTPS-трафика (например, через Wi-Fi).

Вращающийся сеансовый файл cookie ID/данные каждые x единиц времени (минут?), И после каждого y количество запросов, предлагается в сообщении блога.

источник

2017-03-09 01:55:17

Повышает ли безопасность идентификатора сеанса?

ответ

Смежные вопросы