Файл cookie Django CSRF доступен через javascript?

Question

На сайте Джанго https://docs.djangoproject.com/en/dev/ref/contrib/csrf/ говорится:

The CSRF protection is based on the following things: 

1. A CSRF cookie that is set to a random value (a session independent nonce, as it is called), which other sites will not have access to. 
2. ... 

После этого, он также заявляет маркер CSRF может быть получен из печенья с помощью JavaScript:

var csrftoken = $.cookie('csrftoken'); 

является ли эти два заявлениями конфликтующих? Скажем, есть атака Cross Origin, тогда злоумышленник может просто получить токен CSRF из cookie, а затем сделать запрос POST с токеном CSRF в заголовке? Может кто-нибудь объяснить это, пожалуйста?

UPDATE

теперь я понимаю, что, только Javascript из того же происхождения, разрешается доступ к куки. Следующий вопрос:

Если запрос POST автоматически добавляет куки-файлы как часть запроса, а значение cookie csrf django совпадает с токеном csrf, тогда запрос на злонамеренный перекрестный источник по-прежнему будет иметь правильный токен CSRF в любом случае? (в cookie)

Answer 1

Я считаю, что this post ответ на ваш вопрос: обновленное

Из-за политики одного источника, злоумышленник не сможет получить доступ к куки действительно. Но браузер добавит cookie в запрос POST в любом случае, как вы упомянули. По этой причине необходимо также выставить токен CSRF из кода (например, в скрытом поле). В этом случае злоумышленник должен знать значение токена CSRF, хранящегося в файле cookie жертвы, в момент создания вредоносной формы. Поскольку она не может получить доступ к файлу cookie, она не может воспроизвести токен в своем вредоносном коде, и атака не удалась.

Теперь можно представить себе другие способы хранения токена, чем в cookie. Дело в том, что злоумышленник не может его получить. И у сервера должен быть способ проверить его. Вы можете представить себе сохранение токена вместе с сеансом на стороне сервера и хранение маркера на некотором «безопасном» пути на стороне клиента («безопасный», что означает, что злоумышленник не может получить к нему доступ).

Вот цитата из OWASP:

В целом, разработчики должны генерировать только этот маркер один раз для текущей сессии. После первоначальной генерации этого токена значение сохраняется в сеансе и используется для каждого последующего запроса до истечения срока действия сеанса. Когда запрос выдается конечным пользователем, компонент на стороне сервера должен проверять существование и действительность токена в запросе по сравнению с токеном, найденным в сеансе. Если токен не найден в запросе или предоставленное значение не соответствует значению в сеансе, тогда запрос должен быть прерван, токен должен быть сброшен, а событие зарегистрировано как потенциальная атака CSRF.

В конце концов, безопасность нужны две вещи:

• токен CSRF должны быть отправлены из кода, что означает, что вредоносный код должен знать это.
• Значок CSRF должен храниться в некотором «безопасном» месте для сравнения (cookie удобен для этого).

Я не специалист, но это мое понимание проблемы. Надеюсь, поможет.

Answer 2

От имени CSRF (Подпрограмма запроса на межсайтовый запрос) вы уже можете догадаться, что злоумышленник должен выполнить запрос с «кросс-сайта» (на другом сайте).

«Ключом к пониманию атак CSRF является распознавание того, что веб-сайты обычно не проверяют, что запрос поступает от авторизованного пользователя. Вместо этого они проверяют только, что запрос поступает из браузера авторизованного пользователя». - quoted here

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

В этом случае в каждой форме Django у вас есть скрытый ввод, называемый «токен CSRF». Это значение генерируется случайным образом и однозначно генерируется во время отображения формы и будет сравниваться после того, как запрос будет выполнен. Таким образом, запрос может быть отправлен только из браузера авторизованного пользователя. Невозможно (я знаю), что злоумышленник может получить этот токен и выполнить вредоносный запрос, который может быть принят бэкэндом Django.

Достаточно ясно?