Токен CSRF истекает во время входа в систему
Я работаю над весенним веб-приложением, и мне нужно избежать проблемы с истекающим токеном csrf на странице входа в систему, потому что, если пользователь слишком долго ждет и пытается войти в систему, только один способ решить проблему с csrf-перезагрузить страницу и попытаться войти снова. Но это не удобно для пользователя, и я хочу избежать этой ситуации.
первый вопрос: возможно ли вообще (по spring security 3.2.4)? Без отключения csrf.
Я попытался использовать security= «none» для страницы входа и весны seciruty «login_check», но он не работает, у меня есть перенаправление бесконечности или я получил ошибку, что нет сопоставления для url»myhost/login_check».
второй вопрос: Как я могу это сделать?
3 ответов
рекомендуемое решение
Я бы сказал, что вы не должны отключать токены csrf на производственном сайте. Вы можете сделать сеанс (и, следовательно, токен csrf) дольше (но он обычно не должен длиться дольше дня, особенно для не вошедших в систему пользователей, поскольку это вектор DOS), но реальным решением может быть автоматическое обновление страницы входа в систему, когда токен csrf истекает. Вы можете использовать
в заголовке страницы входа. Если пользователь позволяет странице входа сидеть для часы, его не должно беспокоить, что страница обновилась.
второй вариант
возможное решение, которое не требует от вас фактического хранения сеансов, но допускает бесконечное время ожидания, заключается в том, что вы можете генерировать свои токены csrf с хэшированием из идентификатора сеанса и серверного секрета:
обратите внимание, однако, что вам нужно действительно копать и переопределять внутренние механизмы spring-security, а именно:
и выберите очень безопасный алгоритм хэширования, предпочтительно sha-512.
Третий способ
у вас может быть небольшой javascript, который вызывает страницу no-op на вашем сервере регулярно (непосредственно перед таймаутом сеанса), таким образом, продлевая сеанс. Это приводит к бесконечному таймауту сеанса, только если браузер включен все время, поэтому аспект DOS смягчается.
Ok, последнее решение
вы можете изменить код проверки маркера CSRF и отключить его для страницы входа в систему. Это фактически синоним второго решения, но специфично для страницы входа в систему, а не для всех анонимных сеансов.
вы можете сделать это, например, установив пользовательский RequestMatcher в HttpSecurity:
другой вариант не будет установлен тайм-аут для сеанса по умолчанию, а затем, когда пользователь аутентифицируется, измените тайм-аут на то, что вы хотите. Вы можете увидеть пример того, как это сделать здесь.
вы также можете сделать свою защиту CSRF полагаться на cookies, а не на состояние сеанса на стороне сервера. Spring Security полностью поддерживает это.
вы получите тайм-аут, Если ваш cookie истекает. Это хорошо масштабируется, так как это в основном без состояния (с точки зрения сервера).
Атака CSRF
Материал на этой странице устарел, поэтому скрыт из оглавления сайта.
Нельзя говорить про AJAX и не упомянуть про важнейшую деталь его реализации – защиту от CSRF-атак.
CSRF (Cross-Site Request Forgery, также XSRF) – опаснейшая атака, которая приводит к тому, что хакер может выполнить на неподготовленном сайте массу различных действий от имени других, зарегистрированных посетителей.
Какие это действия – отправка ли сообщений, перевод денег со счёта на счёт или смена паролей – зависят от сайта, но в любом случае эта атака входит в образовательный минимум веб-разработчика.
Злая форма
«Классический» сценарий атаки таков:
Вася попал на «злую страницу», например хакер пригласил его сделать это письмом или как-то иначе.
На злой странице находится форма такого вида:
Сайт mail.com проверяет куки, видит, что посетитель авторизован и обрабатывает форму. В данном примере форма предполагает посылку сообщения.
Итог атаки – Вася, зайдя на злую страницу, ненароком отправил письмо от своего имени. Содержимое письма сформировано хакером.
Защита
В примере выше атака использовала слабое звено авторизации.
Куки позволяют сайту mail.com проверить, что пришёл именно Вася, но ничего не говорят про данные, которые он отправляет.
Иначе говоря, куки не гарантируют, что форму создал именно Вася. Они только удостоверяют личность, но не данные.
Типичный способ защиты сайтов – это «секретный ключ» ( secret ), специальное значение, которое генерируется случайным образом при авторизации и сохраняется в сессии посетителя. Его знает только сервер, посетителю мы его даже не будем показывать.
Разумеется, для разных посетителей secret будет разным.
Формула вычисления токена:
Далее, токен добавляется в качестве скрытого поля к каждой форме, генерируемой на сервере.
Такой токен также называют «подписью» формы, которая удостоверяет, что форма сгенерирована именно на сервере.
Эта подпись говорит о том, что автор формы – сервер, но ничего не гарантирует относительно её содержания.
Есть ситуации, когда мы хотим быть уверены, что некоторые из полей формы посетитель не изменил самовольно. Тогда мы можем включить в MD5 для формулы токена эти поля, например:
Токен и AJAX
Теперь перейдём к AJAX-запросам.
Что если посылка сообщений в нашем интерфейсе реализуется через XMLHttpRequest?
Как и в случае с формой, мы должны «подписать» запрос токеном, чтобы гарантировать, что его содержимое прислано на сервер именно интерфейсом сайта, а не «злой страницей».
Здесь возможны варианты, самый простой – это дополнительная кука.
Код, осуществляющий XMLHttpRequest, получает куку и ставит заголовок X-CSRF-TOKEN с ней:
Сервер проверяет, есть ли заголовок и содержит ли он правильный токен.
Защита действует потому, что прочитать куку может только JavaScript с того же домена. «Злая страница» не сможет «переложить» куку в заголовок.
Если нужно сделать не XMLHttpRequest, а, к примеру, динамически сгенерировать форму из JavaScript – она также подписывается аналогичным образом, скрытое поле или дополнительный URL-параметр генерируется по куке.
Итого
CSRF-атака – это когда «злая страница» отправляет форму или запрос на сайт, где посетитель, предположительно, залогинен.
Если сайт проверяет только куки, то он такую форму принимает. А делать это не следует, так как её сгенерировал злой хакер.
Для подписи XMLHttpRequest токен дополнительно записывается в куку. Тогда JavaScript с домена mail.com сможет прочитать её и добавить в заголовок, а сервер – проверить, что заголовок есть и содержит корректный токен.
Динамически сгенерированные формы подписываются аналогично: токен из куки добавляется как URL-параметр или дополнительное поле.
