Каковы некоторые примеры, когда программисты могут захотеть использовать csrf_exempt?

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

Django предоставляет декоратор csrf_exempt. чтобы отключить это поведение. Каковы веские причины, по которым программисты могут захотеть его использовать?

Это подробно описывает, почему это может быть опасно, мне интересно в том, как это может быть полезно.

Я ищу неочевидные ответы (например, незнание того, как использовать защиту CSRF или временно отключить ее).


python django csrf django-csrf csrf-protection
person Vlad Schnakovszki    schedule 29.03.2016    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Например, мы используем его для интерфейса, в котором другая сторона публикует данные программно. Таким образом, они никогда не смогут получить токен csrf. Однако страница защищена базовой аутентификацией.

person schwobaseggl    schedule 29.03.2016

arrow_upward
3
arrow_downward

В проекте, над которым я работаю, есть крошечные встроенные устройства, которые общаются по HTTP с сервером приложений django через VPN. HTTP-клиент на них очень примитивен, поэтому мы отключаем CSRF.

person Mad Wombat    schedule 29.03.2016

arrow_upward
2
arrow_downward

Всякий раз, когда ваш клиент отправляет запрос на сервер, вместе с запросом будет отправлена ​​некоторая конфиденциальная информация. Токен CSRF предотвращает злоупотребление этой информацией вредоносным сайтом. В частности, это предотвращает отправку вредоносным сайтом поддельного запроса, который использует ваши файлы cookie и/или сеанс для аутентификации вашего клиента и авторизации действия. Любая информация, которая автоматически и неявно отправляется по каждому запросу вашего клиента, уязвима для атаки CSRF (хотя не вся информация может быть действительно полезной в такой атаке).

Декоратор @csrf_exempt можно безопасно использовать для обхода механизма защиты CSRF тогда и только тогда, когда действия на стороне сервера, являющиеся результатом запроса, не зависят от проверки подлинности и авторизации, которые неявно отправляются клиентом. Примерами являются проверка подлинности на основе токенов и обычная проверка подлинности HTTP. Для этих форм проверки подлинности клиент должен явно отправлять токен или учетные данные для каждого запроса. Если вредоносный сайт подделывает запрос, он не может отправить требуемую информацию для аутентификации на сервер (если только другая уязвимость не раскрывает эту информацию), и запрос отклоняется. В таких случаях CSRF не предлагает никакой дополнительной защиты.

person knbk    schedule 29.03.2016