the csrf token is invalid что это значит

Источник

Типичные ошибки при защите сайтов от CSRF-атак

В настоящее время в сфере обеспечения безопасности веб-сайтов и приложений возникла очень интересная ситуация: с одной стороны, некоторые разработчики уделяют особое внимание безопасности, с другой, они напрочь забывают о некоторых видах атак и не считают ошибки, позволяющие выполнить данные атаки, уязвимостями. Например, к такой категории можно отнести CSRF (Сross Site Request Forgery). Эта атака позволяет производить различные действия на уязвимом сайте от имени авторизованного пользователя. Если вы не слышали о таком, то я рекомендую прочитать соответствующую статью в Википедии, чтобы иметь общее представление об этом виде атак. Основная часть статьи предназначена тем, кто обеспокоен правильной защитой своих сайтов от CSRF.

Замечание 1: если подходить формально, то CSRF является атакой, а не уязвимостью, как и XSS. Уязвимостью является неправильная обработка входных данных, а CSRF это использует.
Замечание 2: если какие-то ошибки показались вам очевидными и не заслуживающими упоминания, то я рад за вас. Однако данный материал основан на реальных уязвимостях крупных сайтов, а каждый пункт показывает ошибку какой-либо команды разработчиков, обернувшуюся дырой в безопасности.

Список ошибок:

1) Полностью отсутствует защита от CSRF.

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

2) Защищены не все запросы.

Я бы поставил эту ошибку на второе место по распространенности. На многих сайтах, где реализована какая-либо защита от CSRF, можно найти уязвимые запросы. Например, если вы воспользуетесь поиском Хабра habrahabr.ru/search/?q=CSRF, то увидите значительное количество статей, повествующих о найденных уязвимостях на тех сервисах, где есть защита.
Вы должны защищать абсолютно все запросы, которые изменяют что-либо на сайте. Вы добавили токен в форму смены адреса электронной почты, и злоумышленник не сможет завладеть аккаунтом вашего пользователя, изменив от его имени почту, а затем и пароль? Здорово. Вот только такая мера бесполезна, если можно просто отправить запрос на перевод денег с аккаунта жертвы на кошелек атакующего, минуя вашу защиту.
Удобство обеспечения безопасности — одна из причин использовать только метод POST для запросов, изменяющих данные пользователя. Если вы следуете этому совету, то необходимо просто убедиться, что все POST-запросы содержат надежный и правильный токен. Об этом речь пойдет ниже.

3) Использование для защиты от CSRF чего-либо, кроме токенов.

Как насчет использования капчи? Я слышал достаточно большое количество вопросов от разработчиков о возможности их использования для защиты от атаки. Мой однозначный ответ — нет. Во-первых, вы явно не будете заставлять пользователя вводить капчу на каждый чих: это приведет к ошибке № 2. Во-вторых, далеко не все способы реализации капч обеспечат вас должной защитой, которую злоумышленник не сможет обойти. Поскольку эта тема является весьма спорной и актуальной, в дальнейшем я посвящу ей отдельную статью.

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

Другим распространённым способом защиты является механизм, при котором с каждой сессией пользователя ассоциируется дополнительный секретный ключ, предназначенный для выполнения запросов. Пользователь посылает этот ключ среди параметров каждого запроса, и перед выполнением каких-либо действий сервер проверяет этот ключ. Преимуществом данного механизма, по сравнению с проверкой Referer, является гарантированная защита от атак данного типа. Недостатками же являются: требования возможности организации пользовательских сессий и динамической генерации HTML-кода активных страниц сайта.

4) Отсутствие проверки анти-CSRF токена при обработке запроса.

Подобную ошибку я встречал на сайтах весьма серьезных компаний, чья безопасность должна быть на высоте.
В самом запросе токен есть, а при его обработке он не проверяется. Можно вставить в это поле любую строку, запрос все равно будет корректно обработан. Комментировать тут особенно нечего, надо только указать, что применение функции isset() php.net/manual/ru/function.isset.php для проверки токена совершенно недопустимо.

5) Частичная проверка анти-CSRF токена.

Данную ошибку я встретил сразу на нескольких крупных сайтах рунета в разных вариациях. Например, один из сайтов использовал токены вида «Имя_пользователя.Текущее_время.Длинное_случайное_число». При этом проверялось только соответствие имени пользователя в токене и логина того, от чьего имени был отправлен запрос. Это немного усложняет атаку, но не делает ее невозможной.

6) Возможность использовать один токен для разных пользователей.

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

7) Недостаточная длина токена.

Ваш токен должен быть настолько длинным, чтобы злоумышленник потратил на его подбор как минимум столько же времени, сколько и на подбор пароля пользователя. Я встречал токены из 2 символов, они не сильно помогут, если кто-то очень сильно захочет осуществить CSRF-атаку.

8) Предсказумые токены.

При разработке алгоритма генерации токена обязательно используйте случайные данные в токене (совет актуален, если вы разрабатываете всю систему с нуля. В случае использования фреймворка или CMS вы должны полагаться на их разработчиков). Поверьте, токен вида «md5(user_id)» — очень плохая идея.

9) Отсутствие токенов в админ-панели или системе для сотрудников техподдержки.

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

10) Передача токенов в открытом виде, особенно в GET-запросах.

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

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

Источник

The CSRF token is invalid. Please try to resubmit the form

I’m getting this error message every time I try to submit the form:

The CSRF token is invalid. Please try to resubmit the form

My form code is this:

15 Answers 15

You need to add the _token in your form i.e

Or, simply add << form_rest(form) >> before the closing tag of the form.

This renders all fields that have not yet been rendered for the given form. It’s a good idea to always have this somewhere inside your form as it’ll render hidden fields for you and make any fields you forgot to render more obvious (since it’ll render the field for you).

Also you can see this error message when your form has a lot of elements.

This option in php.ini cause of problem

Problem is that _token field misses PUT (GET) request, so you have to increase value.

Also, it concerns a big files. Increasing the

option will solve problem.

This happens because forms by default contain CSRF protection, which is not necessary in some cases.

You can disable this CSRF protection in your form class in getDefaultOptions method like this:

If you don’t want to disable CSRF protection, then you need to render the CSRF protecion field in your form. It can be done by using << form_rest(form) >> in your view file, like this:

<< form_rest(form) >> renders all fields which you haven’t entered manually.

Before your tag put:

It will automatically insert other important (hidden) inputs.

I had this issue with a weird behavior: clearing the browser cache didn’t fix it but clearing the cookies (that is, the PHP session ID cookie) did solve the issue.

This has to be done after you have checked all other answers, including verifying you do have the token in a hidden form input field.

In addition to others’ suggestions you can get CSRF token errors if your session storage is not working.

In a recent case a colleague of mine changed ‘session_prefix’ to a value that had a space in it.

This broke session storage, which in turn meant my form could not obtain the CSRF token from the session.

If you have converted your form from plain HTML to twig, be sure you didn’t miss deleting a closing tag. Silly mistake, but as I discovered it’s a possible cause for this problem.

The problem was, the view I was working with was one that I had converted from plain HTML to twig, and I had missed deleting the closing tag, so instead of :

Obviously the solution is to delete the extra closing tag and maybe drink some more coffee.

Источник

Invalid csrf token with POST request #176

Comments

Vasanthkesavan commented Dec 9, 2018 •

There are three routes which don’t require the checks(auth, register, logout). There are two routes which require checks (GET /api/testget and POST /api/test), the get request works as expected but not the post request.

I have been trying to get the POST request working but it fails everytime with the error «Invalid CSRF token».

The text was updated successfully, but these errors were encountered:

zelongc commented Dec 9, 2018

Hi, The reason you get the error ‘Invalid CSRF token’ is, the csurf middleware tried to get the csrf token in the header of request but failed. so you will need to send your csrf token through html/cookie (maybe you need to use the header in your case).

To get a csrf token : const token = req.csrfToken() Then to put it in the cookie: res.cookie(‘csrf-token’, token)

Then your client side will be able to catch this token (you need to code this function) and send back to the server through the header or in a request body.

Vasanthkesavan commented Dec 10, 2018

Hi, the header is set in the request. Please take a look at the screenshot.

Also, after I authenticate the user everything is detected by the browser and set in the storage properly.

zelongc commented Dec 10, 2018

@Vasanthkesavan Oh sorry my bad, I missed that line.

Just looked through your code above again, though not 100% sure, based on what I observed in your routing config, Only the request falls in the routes after app.use(csurf()) can be assigned a csrf-token, however, you are checking csrf token here. So there is a chance that you haven’t assign the csrfToken but the middleware is doing the csrf check.

I think this is what’s happening to you now:

Did you try to GET /api/testget and do the POST after this?

Hope this could help you.

Vasanthkesavan commented Dec 10, 2018

The GET /api/testget endpoint works correctly and infact any GET request works(after the middleware) except for the POST requests.

dougwilson commented Dec 13, 2018

Hi @Vasanthkesavan GET requests are not checked for the token by default, so by default GET requests will always work.

Is it possible you can provide all the following so we can run your app and try and debug what the issue is here?

Источник

Invalid csrf token. #715

Comments

freder commented Dec 5, 2014

I just installed gogs (0.5.8.1130 Beta) and tried to create a new repository, but when I submit the form all I get is this message:

any idea what’s going wrong here?

The text was updated successfully, but these errors were encountered:

unknwon commented Dec 5, 2014

Thanks your feedback, refresh the page should resolve the issue, it usually happens when you restart the Gogs after you open the web page.

If you can provide 100% reproduce steps, would be a lot helpful!

freder commented Dec 7, 2014

refreshing the page didn’t help, but reopening the page in a new tab did. — thanks!

unknwon commented Dec 7, 2014

ahoehne commented Mar 1, 2015

just faced the problem, but there was no restart of gogs server since i opened chrome. so it might be a caching problem that is probably not coming from the create repo page (reload there didnt helped). reload of start page and after that reload of create repo page solved the problem.

unknwon commented Mar 2, 2015

@ahoehne thanks for the tip!

Did you made sure all dependencies are up-to-date?

ahoehne commented Mar 8, 2015

unknwon commented Mar 8, 2015

@ahoehne I see, thanks again!

unknwon commented Jul 25, 2015

Close discussion for now.

JokerQyou commented Sep 25, 2015

I’ve seen this issue like 2 or 3 times a day. I know how to solve it, but I don’t know why it’s happening.
For one time I noticed that there’s two csrf related cookies there, one is for / and the other for /projects (my Gogs server is behind nginx, and rewrited to /projects/ path). I’ll report if I find any other clues.

unknwon commented Sep 25, 2015

From what I found, if I switch between two Gogs instances, this error can occur, but haven’t had an idea about why this happens.

buzz commented Nov 6, 2015

Happens several time a day while creating repositories or updating issues.
The work around is to close and re-open the page. I didn’t restart the server in between.

I’m on Version: 0.6.15.0926 Beta

ChangePlaces commented Nov 6, 2015

I think these are the exact steps to reproduce:

To resolve, you can just press back, refresh (which leaves your text there) then submit again. But this is messy. As a (hopefully) temporary solution, I’m using a reload plugin for firefox which reloads the issue pages every x minutes. (I have the tabs pinned open)

SR-G commented Feb 28, 2016

Reopening gogs in a private session solved the problem (but no luck by just refreshing the page).
(under Opera 35.0.2066.68 / Windows 8.1)

ChangePlaces commented Feb 28, 2016

neolit123 commented Mar 2, 2016

i had this issue today, creating a test organisation @ try.gogs.io.
after changing the name to something random (zzz) it worked:

unknwon commented Mar 2, 2016

@neolit123 thanks for the tip but this is an old issue, please comment on the latest one #1891

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник