Ранее я обсуждал Шаблон токенов синхронизатора как одно из решений для атаки подделки межсайтовых запросов на веб-приложения.
В этом сообщении блога обсуждается шаблон Double Submit Cookie для предотвращения атаки CSRF.
Что это значит?
Двойная отправка файлов cookie определяется как отправка случайного значения как в файле cookie, так и в качестве параметра запроса, при этом сервер проверяет, равны ли значение файла cookie и значение запроса.
Как это работает?
Когда пользователь аутентифицируется на сайте, сайт должен сгенерировать идентификатор сеанса и установить файл cookie в браузере. В то же время он генерирует криптографически стойкое случайное значение или токен CSRF для сеанса и устанавливает его как файл cookie на компьютере пользователя отдельно от идентификатора сеанса. Серверу не нужно каким-либо образом сохранять это значение, поэтому этот паттерн иногда также называют Stateless CSRF Defense.
Затем сайт требует, чтобы каждый запрос включал это случайное значение в качестве скрытого значения формы (или другого параметра запроса). Злоумышленник из другого источника не может прочитать какие-либо данные, отправленные с сервера, или изменить значения файлов cookie в соответствии с политикой одного и того же источника.
В случае этого метода смягчения последствий работа клиента очень проста; просто извлеките файл cookie CSRF из ответа и добавьте его в специальный заголовок ко всем запросам.
Давайте посмотрим пример проекта,
Это приложение разработано с использованием PHP и JS (ссылка на Github — нажмите здесь)
Во-первых, вам необходимо авторизоваться в приложении, введя логин и пароль. Для демонстрации я жестко запрограммировал учетные данные (имя пользователя: admin, пароль: nikoniko).
Эта форма входа отправляет учетные данные пользователя с использованием метода POST. если пользователь успешно аутентифицирован, на стороне сервера будет создан уникальный идентификатор сеанса и токен CSRF, но сервер сохранит только идентификатор сеанса. Важно отметить, что в этом сценарии сервер не хранит токен CSRF.
Затем сервер ответит соответствующим токеном CSRF вместе с телом ответа. После этого сгенерированный идентификатор сеанса и сервер отвечают на токен CSRF, установленный в виде файлов cookie в браузере.
Здесь мы должны установить флаг httponly «false», потому что js должен иметь доступ к файлу cookie токена csrf, чтобы добавить его в скрытое поле в почтовом запросе.
Затем после того, как пользователь будет перенаправлен на страницу обновления статуса пользователя. На этой странице я реализовал самостоятельный вызов, чтобы получить сохраненный токен CSRF из файлов cookie браузера.
Затем соответствующий токен CSRF добавляется в скрытое поле.
Я реализовал запрос POST, чтобы обновить некоторый статус пользователя. Почтовый запрос содержит этот сгенерированный токен CSRF и файл cookie сеанса.
Когда пользователь нажимает кнопку «updatepost», отправляется запрос на публикацию. Затем сервер проверяет заголовок файла cookie для идентификатора сеанса, а также сервер сравнивает токен CSRF из тела запроса (значение скрытого поля) с токеном CSRF из файла cookie заголовка. Если эти токены совпадают, сервер принимает запрос.
Как мы можем сказать, что метод безопасен?
Файлы cookie отправляются автоматически с каждым запросом, независимо от того, был ли запрос инициирован исходным сайтом или сторонним сайтом. Вот почему одного файла cookie недостаточно, поскольку каждый запрос будет содержать его.
Но имея токен также в самом запросе, атакующий сайт больше не может генерировать действительные запросы, поскольку они не могут завладеть токеном пользователя.
Вывод
Описанные в этой статье методы Double Submit Cookie Pattern жизнеспособны и заслуживают внимания для любого приложения, которое содержит полезные данные.
