Контроль безопасности cookie¶

Контроль безопасности cookies играет ключевую роль в обеспечении защиты данных пользователей и предотвращении несанкционированного доступа к конфиденциальной информации. Каждый файл cookie представляет собой пару key=value, дополненную рядом атрибутов, которые определяют, когда и где используется этот файл cookie. Cookie могут содержать информацию о взаимодействии пользователя с сайтом, такую как настройки, предпочтения, идентификатор сессии и даже личные данные.

Вебмониторэкс осуществляет контроль файлов cookie, которые устанавливает веб-сервер (приложение), с помощью триггера Контроль безопасности cookie. Используя триггер Контроль безопасности cookie можно обнаружить в трафике cookie, потенциально уязвимые к следующим видам атак OWASP Top 10: «А01 Нарушения контроля доступа» и «А02 Криптографические сбои».

Возможные уязвимости cookie и меры по их защите¶

Отсутствие флага безопаcности HttpOnly¶

Флаг HttpOnly в cookie означает, что эти cookie не могут быть доступны или изменены через JavaScript на стороне клиента. Когда установлен флаг HttpOnly, браузер запрещает скриптам JavaScript получать доступ к содержимому cookie через свойства Document.Cookie или другие методы.

Это полезная мера безопасности, которая помогает защитить cookie от атак, таких как XSS. XSS-атаки могут возникнуть, когда злоумышленник внедряет вредоносный код JavaScript на веб-страницу и пытается получить доступ к cookie пользователя. Установка флага HttpOnly обеспечивает дополнительный уровень защиты пользователей сайта.

Отсутствие флага безопаcности Secure¶

Флаг Secure в cookie означает, что браузер должен отправлять эти cookie только через защищенное соединение HTTPS. Когда установлен флаг Secure, браузер не будет отправлять cookie по незащищенным протоколам, таким как HTTP.

Использование флага Secure для cookie особенно важно при работе с конфиденциальными данными, такими как аутентификационные данные или сессионные идентификаторы. Это помогает предотвратить перехват и злоупотребление этими данными злоумышленниками.

Если cookie имеет флаг Secure и пытается быть установленным через незащищенное соединение, браузер будет игнорировать эти cookie и не сохранит их.

Отсутствие флага безопаcности SameSite¶

SameSite-атрибут определяет, должен ли браузер отправлять эти cookie при запросах, инициированных с других сайтов.

Значение SameSite может быть одним из трех вариантов:

SameSite=None – означает, что сookie может быть отправлено на другие домены. Это используется для поддержки функциональности межсайтовых запросов (cross-site requests), таких как AJAX-запросы или запросы, инициированные через <img> или <iframe>. Однако для использования этого значения необходимо также установить атрибут Secure, чтобы гарантировать, что сookie будут отправлены только по защищенному протоколу HTTPS.

SameSite=Strict – в этом случае сookie не будут отправлены на другие домены. Отправка возможна только в том случае, если запрос инициирован с того же домена, на котором установлены cookie.

SameSite=Lax – это значение является компромиссом между Strict и None. Cookie будут отправлены на другие домены, если пользователь переходит на другой сайт, например, щелкая на ссылку. Однако оно не будет отправлено при запросах, инициированных с помощью AJAX, <img> или <iframe>.

Цель SameSite состоит в предотвращении атак, связанных с межсайтовой подделкой запроса (CSRF), при которых злоумышленник может попытаться выполнить действия от имени пользователя на другом сайте. Установка правильного значения SameSite помогает защитить пользователей от таких атак.

Большие значения атрибутов времени жизни Expires/Max-Age¶

Атрибут Expires в cookie указывает на дату и время истечения срока действия cookie. Когда браузер получает cookie с установленным Expires, он сохраняет его на компьютере пользователя до указанной даты и времени.

Атрибут Max-Age в cookie указывает продолжительность срока действия cookie в секундах от момента создания. Когда браузер получает cookie с установленным Max-Age, он сохраняет его на компьютере пользователя и автоматически удалит его после указанного времени.

Например, если значение Max-Age установлено на 3600 (1 час), то cookie будут храниться на компьютере пользователя в течение 1 часа с момента создания. После этого срока действия cookie будут автоматически удалено из браузера.

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

Некорректно настроенные параметры доступа Domain/Path¶

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

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

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

Корректно: для cookie, которые должны быть доступны только на secure.example.com, указан Domain=secure.example.com.

Некорректно: указан Domain=.example.com, если у вас есть небезопасные субдомены, через которые могут быть украдены cookie.

Параметр Path
Параметр Path определяет путь на сервере, для которого cookie действительны. Браузер отправит cookie только при запросах, соответствующих этому пути. Это означает, что сookie будут отправляться только на страницы, находящиеся в указанном пути или его подпутях.

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

Корректно: для cookie, которые должен работать только на /account/settings, указан Path=/account/settings.

Некорректно: указан Path=/, так как это делает cookie доступными для всего сайта.

Чтобы минимизировать риски доступа со стороны небезопасных частей приложения или небезопасных субдоменов, важно сужать область действия cookie с помощью корректной настройки параметров Path и Domain.

Принцип работы триггера Контроль безопасности cookie¶

Создайте триггер, чтобы контролировать безопасность cookie: заполните поля Наименование и Описание, укажите условия, добавьте фильтры и реакцию.

• Триггер будет детектировать уникальные cookie в потоке трафика, которые попадают под параметры триггера.

• Уникальность cookie определяется по сочетанию домена, который установил cookie, с параметрами cookie: NAME+Domain+path.

• При первом обнаружении cookie, попадающих под параметры триггера, заводится уникальная уязвимость с типом «Безопасность cookie» и средним уровнем риска.

• Если cookie попадают под критерии нескольких триггеров, то в соответствующей уязвимости обновляется информация о тех триггерах, которые ее обнаружили.

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

• Закрытие уязвимостей типа «Безопасность cookie» возможно только вручную. Если остались параметры cookie, попадающие под какой-либо триггер, то уязвимость переоткроется. Подробнее о просмотре уязвимостей →

Пример триггера для контроля безопасности cookie¶

Цель: обнаруживать уязвимые куки в нашем приложении panda, в которых пропущены сразу все флаги безопасности.

1. Создайте триггер с типом Контроль безопасности Cookie.

   

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

2. Задайте хотя бы один фильтр.

   После выбора необходимых параметров триггера необходимо задать хотя бы один фильтр. В примере это приложение panda.

   

3. Добавьте реакцию.

   После выбора фильтров нужно выбрать, как система будет реагировать при обнаружении cookie, попадающих под условия выше. В примере — зарегистрировать уязвимость.

   

4. Нажмите Создать.
   Теперь триггер будет отображаться в разделе Триггеры.

Создание триггера →
Отключение и удаление триггеров →