Блог

Теперь схема авторизации выглядит так: если пользователь вводит правильные данные, сервер генерирует уникальный ключ сеанса, вставляет его в таблицу сеансов с FK для этого пользователя. В ответ на запрос JSON я отправляю этот ключ сеанса. Веб-клиент устанавливает этот ключ в файле cookie.

Но проблема в том, что если веб-клиент хранит эти файлы cookie, JS будет иметь к ним доступ, а это небезопасно. Альтернативой является установка файла cookie только для HTTP. Но неясно, необходимо ли в этом случае использовать промежуточное программное обеспечение CSRF. Решает ли атрибут HttpOnly проблему атак XSS / CSRF? Если это не решает, и вам нужно промежуточное программное обеспечение CSRF, то файл cookie csrf должен быть файлом cookie сеанса.

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

Давайте начнем с утверждения, что Межсайтовые сценарии (XSS) и Подделка межсайтовых запросов (CSRF)-это два разных животных.

• XSS-это внедрение вредоносного кода в сайт для его выполнения на клиентской машине. Никакой флаг HttpOnly не может смягчить это.
• CSRF-это внедрение вредоносного кода на какой-либо сторонний сайт и отправка вам ссылки на сторонний сайт. Вредоносный код может попытаться запустить запрос GET/POST (который может обойти ту же политику происхождения браузеров) и выполнить некоторые нежелательные действия на сайте, на который вошел пользователь. Это легче понять на примере:
  1. Вы вошли на свой сайт на https://example.com. Вы аутентифицируетесь с помощью файла cookie.
  2. Кто-то отправляет вам ссылку на https://malicious.net. Вы открываете ссылку в отдельной вкладке браузера.
  3. Вредоносный код выполняется и запускает запрос на https://example.com/deleteAccount=1. Файл cookie будет прикреплен, запрос будет аутентифицирован и выполнен.

Ответ отрицательный — флаг HttpOnly не смягчит ничего из этого. Но давайте сосредоточимся на решении проблемы CSRF. Какие у вас есть варианты?

На самом деле у вас их много: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

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