Остановить регенерацию/аннулирование CSRF при аутентификации

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

Проблема в том, что если это поле отображается после аутентификации, токены CSRF становятся недействительными. Я подтвердил это, позволив себе отправить форму без проверки подлинности, и $form->isValid() возвращает true, тогда как после входа в систему он дает мне false с ошибкой:

Токен CSRF недействителен. Пожалуйста, попробуйте повторно отправить форму.

Я предполагаю, что есть три решения: запретить Symfony регенерировать/аннулировать токены CSRF при аутентификации, удалить токены CSRF из этих форм или сгенерировать мою форму после аутентификации (однако я бы предпочел этого избежать). Мое текущее решение состоит в том, чтобы передать новый токен CSRF обратно с аутентификацией и установить значение токена формы input.

Дополнительно: кто-нибудь знает, как просмотреть все назначенные токены CSRF? Сессия, похоже, их не удерживает.


forms csrf symfony-2.3
person Prisoner    schedule 09.08.2013    source источник
comment
Страница не перезагружается после авторизации?   -  person lsouza    schedule 09.08.2013
comment
@Hisamu Нет, вход в систему осуществляется с помощью ajax, поэтому пользователь входит в систему, а затем я открываю форму при успешном входе в систему. Это момент, когда токены становятся недействительными (по-видимому). Если бы я знал, где просмотреть все токены, я бы смог отладить это дальше.   -  person Prisoner    schedule 09.08.2013
comment
Возможно, вы могли бы восстановить другие токены? См.: stackoverflow.com/a/11632713/209585   -  person lsouza    schedule 09.08.2013
comment
@Hisamu, я думал об этом, но с количеством форм, которые я в конечном итоге буду использовать, я бы предпочел, чтобы Symfony не аннулировал токены csrf! Но если я не смогу, я думаю, мне придется пойти другим путем.   -  person Prisoner    schedule 09.08.2013
comment
Форма правильно отправляется с помощью ajax? ссылка Есть фрагменты кода?   -  person Dickriven Chellemboyee    schedule 12.08.2013
comment
@ Челлем не совсем. Мне пришлось бы опубликовать кучу кода, чтобы кто-то воспроизвел это. Я надеюсь, что кто-то уже сталкивался с этой проблемой   -  person Prisoner    schedule 13.08.2013
comment
Надеюсь, это поможет stackoverflow.com/questions/15044408/   -  person plain jane    schedule 16.08.2013
comment
Хотя я вижу вашу потребность, я думаю, что сложность аннулирования токена, вероятно, задумана. Токен CSRF предназначен для предоставления уникальной подписи запросам, чтобы сдерживать пользователей-злоумышленников, которые хотят автоматизировать атаки или захватывать сеансы других пользователей. Вместо того, чтобы пытаться остановить регенерацию, кажется, лучше принять ее и найти решение, которое будет хорошо сочетаться с ней.   -  person Mark Fox    schedule 28.08.2013
comment
@MarkFox Я понял это, и я вижу причины для признания недействительными любых токенов запроса при неаутентификации, но я действительно не вижу достаточно веских причин для признания их недействительными при аутентификации. Я нашел решение, которое я указал в исходном вопросе - мне просто интересно, сталкивался ли кто-нибудь еще с этой же проблемой и нашел более элегантное решение.   -  person Prisoner    schedule 28.08.2013
comment
@Prisoner На мой взгляд, имеет смысл, что токены CSRF будут привязаны к идентификаторам пользователей, это кажется более простым. Скажем, пользователь начинает с http, отправляет форму, затем аутентифицируется через https - поскольку токен не изменился, злоумышленник может Man In The Middle или XSS незашифрованный POST, получить доступ к токену и потенциально начать возиться с сеансом аутентифицированных пользователей. Очевидно, это зависит от некоторых конкретных предположений, но хорошая структура предполагает разумное худшее.   -  person Mark Fox    schedule 28.08.2013
comment
Если вы не перегенерируете CSRF при входе в систему, вы можете стать уязвимыми для атак с фиксацией: злоумышленник создает сеанс, сохраняет ключ CSRF, заставляет пользователя войти в этот сеанс с отбрасыванием файлов cookie, ждет, пока пользователь войдет в систему, а затем может отправлять поддельные запросы с действительными токенами CSRF.   -  person Tgr    schedule 04.09.2013
comment
Я вернулся со ссылкой, но @Tgr уже опередил меня; в любом случае вот ссылка о фиксации сеанса: cwe.mitre.org/data/definitions/384 .html   -  person Mark Fox    schedule 25.10.2013

Ответы (2)


arrow_upward
0
arrow_downward

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

Однако, если вы действительно не хотите этого делать, Вы сказали:

Мое текущее решение состоит в том, чтобы передать новый токен CSRF обратно с аутентификацией и установить входное значение токена формы.

Просто сделай это. Там нет ничего плохого.

person Ben    schedule 17.09.2013

arrow_upward
0
arrow_downward

Спасибо @MarkFox за указание на эту CWE, хотя я знал, что это с помощью дизайна я надеялся, что у меня будет способ избежать пути, по которому я закончил.

Для всех, кто заинтересован, CWE заявляет:

Аутентификация пользователя или иное установление нового сеанса пользователя без аннулирования любого существующего идентификатора сеанса дает злоумышленнику возможность украсть аутентифицированные сеансы.

По этой причине я рекомендую вам пойти по пути, который я закончил, отправив новые токены запроса через AJAX и поместите их в соответствующие формы.

person Prisoner    schedule 25.10.2013