Предоставляет ли токен безопасности CSRF безопасности?

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

Я бы хотел использовать AJAX для некоторых POST-запросов, но у упомянутых запросов нет доступного токена CSRF. Страницы не имеют элементов <form>, и я не хочу мутить разметку, вставляя токен в скрытое значение. Я считаю, что хороший способ сделать это - выставить vew как /get-csrf-token/, чтобы вернуть токен пользователя, опираясь на правила межсайтового скриптинга браузера, чтобы предотвратить нежелательные сайты от его запроса.

Это хорошая идея? Существуют ли более эффективные способы защиты от атак CSRF при одновременном разрешении AJAX-запросов?

Ответ 1

Если вы знаете, что вам нужен токен CSRF для запросов AJAX, вы всегда можете вставлять его в HTML; то вы можете найти его через Javascript, пройдя DOM. Таким образом, у вас все равно будет доступ к токену, но вы не будете открывать его через API.

Другими словами: делайте это через шаблоны Django - не через диспетчер URL. Это гораздо более безопасно.

Ответ 2

UPDATE: ниже было верно и должно быть правдой, если все браузеры и плагины были правильно реализованы. К сожалению, теперь мы знаем, что это не так, и что некоторые комбинации плагинов и переадресаций браузера могут позволить злоумышленнику предоставлять произвольные заголовки в кросс-доменном запросе. К сожалению, это означает, что даже запросы AJAX с заголовком "X-Requested-With: XMLHttpRequest" теперь должны быть защищены CSRF. В результате Django больше не освобождает запросы Ajax от защиты CSRF.

Оригинальный ответ

Следует отметить, что защита запросов AJAX от CSRF не нужна, поскольку браузеры не разрешают запросы AJAX на разных площадках. Фактически, промежуточное ПО Django CSRF теперь автоматически освобождает запросы AJAX от сканирования токенов CSRF.

Это допустимо только в том случае, если вы фактически проверяете серверную часть заголовка X-Requested-With для значения "XMLHttpRequest" (что делает Django) и освобождаете от настоящих запросов AJAX из CSRF-сканирования.

Ответ 3

Отмените это, я ошибся. (См. Комментарии.). Вы можете предотвратить эксплойт, гарантируя, что ваш JSON следует спецификации: всегда убедитесь, что вы возвращаете объектный литерал как объект верхнего уровня. (Я не могу гарантировать, что дальнейших эксплойтов не будет. Представьте, что браузер предоставляет доступ к поврежденному коду в его события window.onerror!)

Вы не можете полагаться на правила межсайтового скриптинга, чтобы сохранять ответы AJAX частными. Например, если вы возвращаете токен CSRF как JSON, вредоносный сайт может переопределить конструктор String или Array и запросить ресурс.

bigmattyh правильно: вам нужно внедрить маркер где-нибудь в разметке. В качестве альтернативы вы можете отклонить любые POST, которые do имеют референт, который соответствует не. Таким образом, только люди с переусердными программными брандмауэрами будут уязвимы для CSRF.