На веб-сайтах обнаружено множество различных типов уязвимостей безопасности, одна интересная из которых называется «Session Fixation». Фиксация сеанса - это проблема, при которой злоумышленник может повлиять на идентификатор сеанса, также известный как идентификатор сеанса пользователя, а затем использовать его для получения доступа к своей учетной записи. Есть два способа работы этого типа уязвимости: он может позволить злоумышленнику либо найти, либо установить идентификатор сеанса другого пользователя.
Как выполняется атака фиксации сеанса
Идентификатор сеанса пользователя часто является ключевой частью аутентификации на веб-сайте и во многих случаях является единственными данными, которые идентифицируют конкретного пользователя, вошедшего в систему. Проблема заключается в том, что если злоумышленник может установить или узнать идентификатор сеанса другого пользователя, он может использовать токен сеанса и затем действовать как пользователь.
Обычно это делается путем обмана пользователя, заставляющего его щелкнуть фишинговую ссылку. Сама ссылка полностью легитимна, но включает в себя переменную, которая устанавливает указанный идентификатор сеанса. Если пользователь затем входит в систему с идентификатором сеанса, а сервер не назначает ему новый идентификатор сеанса на входа в систему, злоумышленник может просто установить одинаковый идентификатор сеанса и получить доступ к учетная запись.
Еще один способ, которым злоумышленник может узнать идентификатор сеанса жертвы, - это его появление в URL-адресе. Например, если злоумышленник может обманом заставить жертву отправить ей ссылку, которая включает идентификатор сеанса жертвы, злоумышленник может использовать идентификатор сеанса для доступа к учетной записи жертвы. В некоторых случаях это может произойти совершенно случайно. Например, если пользователь копирует URL-адрес с идентификатором сеанса и вставляет его другу или на форум, любой пользователь, который перейдет по ссылке, войдет в систему с учетной записью пользователя.
Исправления фиксации сеанса
Есть несколько решений этой проблемы, и, как всегда, лучшим решением является внедрение как можно большего числа исправлений в рамках стратегии глубокоэшелонированной защиты. Первое решение - изменить идентификатор сеанса пользователя при входе в систему. Это предотвращает возможность злоумышленника повлиять на идентификатор сеанса вошедшего в систему пользователя. Вы также можете настроить сервер так, чтобы он принимал только идентификаторы сеансов, которые он сгенерировал, и явно отклонять любые идентификаторы сеансов, предоставленные пользователем.
Веб-сайт должен быть настроен так, чтобы никогда не помещать какие-либо конфиденциальные данные пользователя, такие как идентификатор сеанса, в URL-адрес, и следует помещать его в параметр запроса GET или POST. Это предотвращает случайную компрометацию пользователем собственного идентификатора сеанса. Используя как идентификатор сеанса, так и отдельный токен аутентификации, вы удваиваете объем информации, который злоумышленник должен получить, и предотвращаете доступ злоумышленников к сеансам с известными идентификаторами сеансов.
Жизненно важно, чтобы все действительные идентификаторы сеанса для пользователя становились недействительными при нажатии кнопки выхода из системы. Можно повторно создавать идентификатор сеанса при каждом запросе, если идентификаторы предыдущих сеансов недействительны, это также предотвращает использование злоумышленниками известного идентификатора сеанса. Этот подход также значительно уменьшает окно угроз, если пользователь раскрывает свой собственный идентификатор сеанса.
За счет включения нескольких из этих подходов стратегия глубокоэшелонированной защиты может устранить эту проблему как угрозу безопасности.