Идентификатор сеанса не обновлен Риск, реальная уязвимость или просто риск ложного срабатывания?

При недавнем сканировании безопасности с использованием IBM AppScan в одном из наших приложений ASP.NET сообщается о следующей средней уязвимости.

Идентификатор сеанса не обновлен
Уровень серьезности: средний
Риск: возможна кража или манипулирование сеанс клиента и файлы cookie, которые могут использоваться для выдачи себя за законного пользователя, позволяя хакеру просматривать или изменять записи пользователя и выполнять транзакции от имени этого пользователя
Причины: Небезопасное программирование или конфигурация веб-приложения .

Я обнаружил, что в разных темах говорится об одном и том же, а также нашел предлагаемые решения. Но в этой статье базы знаний Microsoft объясняет, как повторное использование идентификаторов сеансов может быть полезным, и эта же статья не Не упоминайте о каких-либо рисках, связанных с повторным использованием идентификаторов сеансов. Также в Идентификаторы сеанса | MSDN никакие упомянутые риски, кроме значений SessionID, не отправляются открытым текстом, будь то файл cookie или часть URL-адреса.

Итак, мой вопрос здесь заключается в том, что риск — это реальная уязвимость/возможная атака с фиксацией сеанса или это просто ложноположительный риск?


person Ahmed Atia    schedule 16.01.2014    source источник


Ответы (2)


Существует вероятность того, что идентификатор сеанса можно легко отследить до аутентификации. Поскольку идентификатор определяет сеанс браузера, поэтому, когда пользователь просматривает страницу входа, будет сгенерирован идентификатор сеанса. поэтому злоумышленник может иметь представление о шаблоне идентификатора сеанса. поэтому лучше измените идентификатор сеанса после успешного входа в систему.

Есть и другие области, в которых вы должны изменить идентификатор сеанса. Вы можете посмотреть на сайте https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

person Pankaj Dey    schedule 22.01.2014

Использование файлов cookie всегда приводит к некоторому уровню уязвимости, если транспортная среда не защищена.

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

Я не могу придумать причину, по которой это было бы специфично для ASP.NET и специфично для cookie сеанса. И я не совсем понимаю, что они имели в виду здесь

[...] украсть или манипулировать сеансом и файлами cookie

Во-первых, «или». Чтобы манипулировать сессией, вы должны сначала украсть ее. Потом "и". Вы не можете манипулировать файлами cookie, вы можете их только украсть.

Это должно быть тогда

Чтобы украсть куки и манипулировать сеансом.

В ответ на такое предупреждение вы должны убедиться, что:

  • общение всегда защищено после выдачи файлов cookie
  • файлы cookie должным образом уничтожаются, когда пользователь выходит из системы или закрывает браузер (постоянные файлы cookie отсутствуют)
person Wiktor Zychla    schedule 16.01.2014