Токены CSRF - как правильно реализовать?

Question

Я только что установил простую защиту CSRF в своем приложении.Он создает уникальную крошку, которая проверяется по значению сеанса при отправке формы.

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

Должен ли я создать отдельный токен для каждой действующей формы или использовать общую крошку для всех моих форм?В чем тут здравый смысл?

Answer 1

Вы можете сделать либо.Это зависит от уровня безопасности, который вы хотите.

OWASP Enterprise Security API (ESAPI) использует один маркер для каждого сеанса пользователя.Вероятно, это довольно эффективный метод, если у вас нет дыр в XSS и у вас достаточно короткие тайм-ауты.Если вы позволяете сеансам оставаться в живых в течение нескольких дней или недель, тогда это не очень хороший подход.

Лично мне не сложно использовать разные токены для каждого экземпляра каждой формы.Я сохраняю структуру в сеансе пользователя с парами ключ-значение.Ключом для каждого элемента является идентификатор формы, а значением является другая структура, содержащая токен и срок действия этого токена.Обычно я позволяю токену жить в течение 10-20 минут, после чего срок его действия истекает.Для более длинных форм я могу дать ему долгое время истечения.

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

Answer 2

Шпаргалка OWASP содержит наиболее точные ответы на подобные вопросы.В нем рассматриваются различные подходы и баланс между безопасностью и удобством использования.

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

Answer 3

Как я знаю о CSRF, вы можете использовать

1) Случайное число и сохранить его в сеансе:
Добавить его к скрытому вводу, называемому скрытым, затем при получении информацииВы можете проверить скрытое поле со значением сеанса

2) Статическая переменная конфигурации (как предыдущий, но без сеанса)
Скрытое поле будет содержать это значение (переменная из конфигурации).При проверке вы проверите скрытое сообщение и значение ключа безопасности конфигурации

3) HTTP Referer
Вы можете использовать http referrer, чтобы узнать, откуда пришел пользователь, и проверить его с помощьюреальный домен (этот метод может атаковать, если ваш сайт содержит xss).

Как я знаю, вы можете использовать любое решение:)