CSRF Запрос одноразового номера делает возможным вредоносный POST? - PullRequest
0 голосов
/ 06 мая 2020

Я пытаюсь осмыслить защиту csrf и кое-что не понимаю. Может быть, кто-нибудь может дать мне необходимую информацию:).

Что я понимаю

Скажем, у нас нет защиты от csrf. Кто-то входит на сайт A со своими учетными данными. После действительного входа в систему в браузере сохраняется сеанс Cook ie. Пользователь ОТПРАВЛЯЕТ некоторые данные через форму, и сервер принимает их без проблем. Поскольку у нас нет защиты csrf, это открывает систему для уязвимости.

Пользователь посещает другой веб-сайт B, вредоносный веб-сайт, например, попытка фишинга. Этот веб-сайт отправляет сообщение на веб-сайт A в фоновом режиме с некоторым запросом javascript xhr, например. В браузере есть Cook ie, сохраненная для веб-сайта A, и, поскольку пользователь уже вошел в систему, это действительный сеанс. Поэтому веб-сайт A примет сообщение без каких-либо проблем.

Для решения этой проблемы используется защита от csrf. При загрузке страницы с формой на веб-сайте A с сервера генерируется одноразовый номер (одноразовый код). Этот код необходимо отправить вместе с формой, чтобы сервер мог проверить, пришло ли это сообщение из того же сеанса, который запросил форму. Если код такой же, как и только что сгенерированный, форма будет принята. Если код отсутствует или неверен, сервер сообщает «нет».

Вопрос

Если вредоносный веб-сайт B сначала делает запрос на получение страницы, которая отображает форму. Затем он сможет получить токен для отправки вместе с почтовым запросом. Правильно? Я упустил что-то очевидное?

Спасибо!

1 Ответ

1 голос
/ 06 мая 2020

Я понимаю, что вас беспокоит то, что вредоносный веб-сайт может запросить ваш токен анти-CSRF.

Вам необходимо предотвратить чтение из разных источников или встраивание страниц или конечных точек, которые возвращают токены CSRF. Одна из важных вещей, о которых следует помнить, заключается в том, что CORS не обеспечивает защиту CSRF, поскольку предварительные запросы CORS не всегда выполняются браузером, например, при использовании обычных форм html.

Большинство современных браузеров по умолчанию блокировать перекрестные запросы. Если вам действительно нужны запросы на перекрестное происхождение для ваших собственных доменов, можете ли вы сделать это, установив правильные заголовки перекрестного происхождения, например Access-Control-Allow-Origin: sub.domain.com. Чтобы предотвратить встраивание в iframe, вы можете реализовать от X-Frame-Options: до DENY или SAMEORIGIN.

Дополнительную информацию можно найти по адресу https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

...