Защита от подделки межсайтовых запросов с помощью Django и веб-сокетов - PullRequest
0 голосов
/ 06 ноября 2018

Я успешно создал веб-сокет на моем веб-сайте с поддержкой Django (версия 2.0), используя каналы Django (версия 2.1.5).

Все хорошо, но мне интересно, что насчет токена CSRF. Это нужно в случае веб-сокетов? Документация говорит, что достаточно использовать OriginValidator, чтобы предотвратить такую ​​ветку, но я бы хотел убедиться в этом. Я имею в виду, что случилось с токеном CSRF? Я просто отправляю данные через защищенный канал без него, а бэкэнд автоматически все проверяет? И если это так, то почему? И почему простые взгляды не могут этого сделать?

Я знаю, что это довольно открытый вопрос, но я не смог найти какое-либо конкретное объяснение, если бы у кого-то было такое, я был бы более чем признателен.

Ура!

1 Ответ

0 голосов
/ 11 ноября 2018

Маркер CSRF не требуется при использовании соединений через веб-сокет.

Когда вы посещаете вредоносный веб-сайт, он может отправить пост-запрос через javascript на другой веб-сайт, на котором вы в настоящий момент авторизованы. Ваш браузер также отправит вам cookie-файл сессии на этот другой веб-сайт, поэтому веб-сервер считает, что вы действительно отправил этот пост-запрос и выполнил бы запрос. CSRF-cookie предотвращает это. Так как вредоносный сайт не может прочитать значение файла CSRF-cookie, он не может добавить значение к пост-запросу.

Также вредоносный веб-сайт может открыть соединение через веб-сокет с другим сайтом. Это причина, почему вы должны использовать OriginValidator. Если вы используете его, то сервер принимает только подключения к веб-сокету с вашего сайта.

Когда вредоносный сайт пытается открыть соединение с вашим сервером, он сразу же отклоняется.

Таким образом, разница между пост-запросом и веб-сокет-соединениями заключается в том, что браузеры отправляют исходный заголовок на веб-сокет-соединениях, но не всегда на почтовые запросы.

Похоже, что современные браузеры всегда отправляют заголовок источника: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin

Так что, возможно, вам вообще не нужно использовать CSRF-cookie. См. Также: Защита CSRF с заголовком CORS Origin против CSRF-токена

...