Маркерное поколение CSRF

Токен CSRF, предназначенный для предотвращения (непреднамеренного) изменения данных, которое обычно применяется с запросами POST.

Таким образом, вы должны включать токен CSRF для каждого запроса, который изменяет данные (либо GET, либо POST запрос).

Мой вопрос по поводу генерация токенов, когда НЕТ уникальные пользовательские данные для использования. Нет сессий доступны, файлы cookie не опция, IP-адрес и тому подобное природа ненадежна.

Затем просто создайте уникальный идентификатор пользователя для каждого посетителя. Включите этот идентификатор в файл cookie или в URL-адреса (если файлы cookie отключены).

Изменить:

Примите во внимание следующее событие:

Вы вошли в свою учетную запись facebook, а затем вошли на какой-то произвольный веб-сайт.

На этом веб-сайте есть форма, которую вы отправляете, которая сообщает вашему браузеру отправить POST-запрос на вашу учетную запись facebook.

Этот POST-запрос может изменить ваш пароль, добавить комментарий и т. Д., Потому что приложение facebook распознало вас как зарегистрированного и вошедшего в систему пользователя. (если нет другого механизма блокировки, например CAPTCHA)

Есть ли причина, по которой я не могу включить строку в хэш как часть запроса?

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

Если вы включите строку для хеширования в запрос, то запрос будет самодостаточным, поэтому копирование формы - это все, что нужно сделать злоумышленнику, поскольку у них есть обе части токен, и, таким образом, защиты нет.

Даже размещение его в форме URL означает, что он самодостаточен, злоумышленник просто копирует форму и URL отправки.

CSRF использует сеанс пользователя, поэтому, если у вас его нет, нет и CSRF.

Вам просто нужен тот же «токен» в URL / форме и в файле cookie. Это означает, что вы можете настроить свою страницу для установки маркера cookie на все, что она хочет (предпочтительно какое-то случайное значение) с помощью JavaScript, а затем просто передать одно и то же значение во всех запросах, которые отправляются на ваш сервер (как параметр URI? Или форма- поле). Не нужно, чтобы ваш сервер генерировал cookie.

Это безопасно, если мы уверены, что браузер не позволяет страницам из одного домена редактировать / читать файлы cookie для других доменов, и сегодня это считается достаточно безопасным.

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

(Если я ошибаюсь, дайте мне знать)