Почему Express/Connect генерирует новый токен CSRF для каждого запроса?

Question

Насколько я понимаю, есть два подхода в области защиты от CSRF атак: 1) знака на сессию, и 2) маркера по запросу

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

2) Во втором случае для каждого запроса создается новый токен CSRF, после чего старая становится недействительной. Это усложняет использование vunerability, потому что даже если злоумышленник крадет токен (через XSS) , он истекает, когда пользователь переходит на следующую страницу. Но, с другой стороны, этот подход делает использование Webapp менее полезным. Вот хорошая цитата из security.stackexchange.com:

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

Когда Node.js Express анализируя структуру (которая основана на Connect) Я заметил, что новый Маркер CSRF генерируется по каждому запросу, , но старый не становится недействительным.

Мой вопрос:: В чем причина предоставления нового токена CSRF по каждому запросу, а не для недействительности старого? Почему бы просто не создать один токен за сеанс?

Спасибо и извините за мой английский!

Answer 1

Знаки CSRF являются нотами. Они должны использоваться только один раз (или безопасно после долгого времени). Они используются для идентификации и авторизации запросов. Рассмотрим два подхода для предотвращения CSRF:

1. Single фишку неподвижную за сессию: Недостаток в том, что клиент может передать свой маркер другим. Это может быть не из-за нюхания, а в случае с мужчиной или в середине или с некоторой задержкой в ​​безопасности. Это предательство со стороны пользователя. Несколько клиентов могут использовать один и тот же токен. К сожалению, ничего нельзя сделать по этому поводу.

2. Динамический токен: токен обновляется каждый раз, когда происходит какое-либо взаимодействие между сервером и клиентом или когда происходит таймаут. Он предотвращает использование старых токенов и одновременное использование от нескольких клиентов.

Недостатком динамического токена является то, что он ограничивает возврат и продолжение оттуда. В некоторых случаях это может быть желательно, например, при использовании корзины покупок, перезагрузка должна проверяться на складе. CSRF не позволит повторно отправить отправленную форму или повторить покупку/продажу.

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

Update

я могу думать только две причины, по единой динамики маркер лучше, чем многократный:

1. Несколько жетонов действительно лучше, но, по крайней мере, один динамический маркер как один выше. Это означает разработку подробного рабочего процесса, который может стать сложным. Например смотрите здесь:

   1. https://developers.google.com/accounts/docs/OAuth2
   2. https://dev.twitter.com/docs/auth/implementing-sign-twitter
   3. https://developers.facebook.com/docs/facebook-login/access-tokens/

   Эти маркеры для доступа к их API (форма представления и т.д.) не только логин. Каждый из них реализует их по-разному. Не стоит делать, если у вас нет хорошего варианта использования. Ваши веб-страницы будут использовать его сильно. Не говоря уже о том, что представление формы не просто сейчас.

2. Динамический одиночный токен является самым простым и доступным в библиотеке. Так можно использовать его на ходу.

Преимущества нескольких лексем:

1. Можно осуществить сделки. Вы можете заказать между запросами.
2. Может быть отказано от таймаута и ошибок аутентификации (вы должны их обработать сейчас).
3. Безопасный! Более надежные, чем одиночные токены. Может обнаруживать неправильное использование маркера, пользователя черного списка.

Кстати, если вы хотите использовать несколько токенов, у вас есть библиотеки OAuth2.