Эффективное использование токенов Cookie и CSRF

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

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

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

Использование токенов CSRF и cookies

Предотвращение CSRF-атак
Хорошей новостью является то, что CSRF-атаку можно легко предотвратить с помощью токена CSRF. Эта практика безопасности использует динамический непредсказуемый токен, связанный с каждым вошедшим в систему пользователем, который меняется с каждым запросом. Этот токен, как скрытое значение на веб-странице текущего сеанса браузера и отправляется вместе с каждым запросом, сделанным пользователем - Гарантируя, что только действия, выполненные на легальной странице, могут получить доступ к этому токену. Давайте рассмотрим безопасную реализацию токенов CSRF на основе форм:

1. Зарегистрированный клиент запрашивает HTML-страницу, которая содержит форму.
2. Сервер включает в себя два токена в ответе. Один токен отправляется как cookie для аутентификации пользователя (Cookie или XSRF-токен). Другой в скрытом поле формы.
3. Когда клиент отправляет форму, оба токена должны быть проверены на стороне сервера перед обработкой запроса.

Последовательность аутентификации действий на стороне сервера должна быть следующей:

1. Идентификатор пользователя должен быть получен из полученных файлов cookie и токена из информации заголовка запроса.
2. Токен из Post данных/формы должен быть проверен - он принадлежит тому же пользователю, который был подтвержден на шаге 1.
3. Обработайте полученную форму для аутентифицированного пользователя.

Внедрение защиты CSRF в Joomla
Joomla изначально предоставляет функции для реализации защиты от CSRF-атак. Реализация этого механизма защиты довольно проста - Joomla уже предоставляет функции для генерации непредсказуемых случайных токенов и функции для проверки их в соответствии с сессиями пользователей. Давайте посмотрим, как мы можем реализовать их для защиты нашего приложения.

Анти-CSRF-токены в Joomla отправляются с использованием форм в запросах POST. Следующий код должен быть включен на странице, чтобы создать этот токен.

<?php echoJHtml::_( 'form.token'); ?> 

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

<input type="hidden"name="0987654321abcdef0987654321abcdef"value="1"/>

Теперь мы также должны написать код для проверки этого сгенерированного токена. Этот код должен быть написан на странице, которая обрабатывает запрос, сгенерированный на предыдущей странице.

// Проверка на подделку запроса

$this->checkToken();

Эта проверка на достоверность токена должна быть записана так, чтобы - проверка на токен обрабатывалась до обработки фактического запроса. Это можно реализовать с помощью функции следующим образом.

JSession::checkToken() ordie( 'Invalid Token');



Где не использовать токены CSRF?
Иногда, если мы используем какую-то функциональность от третьих лиц, токены CSRF не должны использоваться - поскольку третья сторона не будет знать, какой токен CSRF отправить в ваше веб-приложение. Например, если вы используете Stripe для обработки платежей и используете их систему webhook, вам необходимо исключить Stripe webhook handler route из защиты CSRF.

Следует отметить, что запрос сценария/HTML с сайта злоумышленника обычно не имеет доступа к вашему токену XSRF или Cookie из-за контроля доступа HTTP. Это примечание особенно важно для людей, которые необоснованно отправляют заголовок Access-Control-Allow-Origin: * для каждого ответа веб-сайта, не зная, для чего он нужен, в основном для получения своего API-интерфейса с другого веб-сайта.

Защита от CSRF для пользователей
С точки зрения пользователя, предотвращение - это защита учетных данных и запрещение несанкционированного доступа к приложениям.

Лучшие практики включают в себя:

• Выходить(вылогиниться) из веб-приложений, когда они не используются.
• Не использовать опцию «Запомнить меня» на страницах входа.
• Не позволяя браузерам запоминать пароли.
• Избегайте одновременного просмотра других сайтов/приложений при входе в конфиденциальное приложение.

Комментировать статью: