Ошибка invalid csrf token

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: <form novalidate action="{{path('signup_...

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:

<form novalidate action="{{path('signup_index')}}" method="post" {{form_enctype(form)}} role="form" class="form-horizontal">
    <div class="form-group">
        {{ form_label(form.email, 'Email', {'label_attr': {'class': 'col-md-1 control-label'}}) }}
        {{ form_widget(form.email, {'attr': {'class': 'col-md-2'}}) }}
        {{ form_errors(form.email) }}
    </div>

    <div class="form-group">
        {{ form_label(form.nickname, 'Nickname', {'label_attr': {'class': 'col-md-1 control-label'}}) }}
        {{ form_widget(form.nickname, {'attr':{'class': 'col-md-2'}}) }}
        {{ form_errors(form.nickname, {'attr': {'class': 'col-md-3'}}) }}
    </div>
    <div class="form-group">
        {{ form_label(form.password, 'password', {'label_attr': {'class': 'col-md-1 control-label'}}) }}
        {{ form_widget(form.password, {'attr': {'class': 'col-md-2'}}) }}
        {{ form_errors(form.password, {'attr': {'class': 'col-md-3'}}) }}
    </div>

    <div class="form-group">
        {{ form_label(form.password_repeat, 'Repeat password', {'label_attr': {'class': 'col-md-1 control-label'}}) }}
        {{ form_widget(form.password_repeat, {'attr':{'class': 'col-md-2'}}) }}
        {{ form_errors(form.password_repeat, {'attr': {'class': 'col-md-3'}}) }}
    </div>
    <div class="form-group">
        <div class="col-md-1 control-label">
        <input type="submit" value="submit">
    </div>

    </div>
</form>

Any ideas?

Don't Panic's user avatar

Don’t Panic

40.8k10 gold badges61 silver badges78 bronze badges

asked May 4, 2014 at 11:38

Francisco Albert's user avatar

Francisco AlbertFrancisco Albert

1,5472 gold badges17 silver badges32 bronze badges

1

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

{{ form_row(form._token) }}

As of now your form is missing the CSRF token field. If you use the twig form functions to render your form like form(form) this will automatically render the CSRF token field for you, but your code shows you are rendering your form with raw HTML like <form></form>, so you have to manually render the field.

Or, simply add {{ form_rest(form) }} before the closing tag of the form.

According to docs

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).

form_rest(view, variables)

Community's user avatar

answered May 4, 2014 at 11:41

M Khalid Junaid's user avatar

M Khalid JunaidM Khalid Junaid

63.3k10 gold badges90 silver badges116 bronze badges

4

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

This option in php.ini cause of problem

; How many GET/POST/COOKIE input variables may be accepted
 max_input_vars = 1000

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

Also, it concerns a big files. Increasing the

upload_max_filesize

option will solve problem.

answered Nov 5, 2014 at 20:39

zalex's user avatar

4

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:

// Other methods omitted

public function getDefaultOptions(array $options)
{
    return array(
        'csrf_protection' => false,
        // Rest of options omitted
    );
}

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 novalidate action="{{path('signup_index')}}" method="post" {{form_enctype(form)}} role="form" class="form-horizontal">
    <!-- Code omitted -->

    <div class="form-group">
        <div class="col-md-1 control-label">
            <input type="submit" value="submit">
        </div>

    </div>
    {{ form_rest(form) }}
</form>

{{ form_rest(form) }} renders all fields which you haven’t entered manually.

answered May 4, 2014 at 20:09

2

Before your </form> tag put:

{{ form_rest(form) }}

It will automatically insert other important (hidden) inputs.

answered May 4, 2014 at 11:46

Lkopo's user avatar

LkopoLkopo

4,7588 gold badges34 silver badges60 bronze badges

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.

answered Mar 31, 2017 at 13:27

Benoit Duffez's user avatar

Benoit DuffezBenoit Duffez

11.5k12 gold badges74 silver badges123 bronze badges

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.

session_prefix: 'My Website'

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

answered Jan 18, 2017 at 3:49

Henry's user avatar

HenryHenry

7,6112 gold badges38 silver badges38 bronze badges

1

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

When I got this error, I couldn’t figure it out at first. I’m using form_start() and form_end() to generate the form, so I shouldn’t have to explicitly add the token with form_row(form._token), or use form_rest() to get it. It should have already been added automatically by form_end().

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 </form> tag, so instead of :

{{ form_end(form) }}

I had:

</form>
{{ form_end(form) }}

That actually seems like something that might throw an error, but apparently it doesn’t, so when form_end() outputs form_rest(), the form is already closed. The actual generated page source of the form was like this:

<form>
    <!-- all my form fields... -->
</form>
<input type="hidden" id="item__token" name="item[_token]" value="SQAOs1xIAL8REI0evGMjOsatLbo6uDzqBjVFfyD0PE4" />
</form>

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

answered Mar 12, 2017 at 19:09

Don't Panic's user avatar

Don’t PanicDon’t Panic

40.8k10 gold badges61 silver badges78 bronze badges

I had this error recently. Turns out that my cookie settings were incorrect in config.yml. Adding the cookie_path and cookie_domain settings to framework.session fixed it.

answered Jun 1, 2017 at 19:20

Michael's user avatar

MichaelMichael

8,4444 gold badges26 silver badges36 bronze badges

I hade the same issue recently, and my case was something that’s not mentioned here yet:

The problem was I was testing it on localhost domain. I’m not sure why exactly was this an issue, but it started to work after I added a host name alias for localhost into /etc/hosts like this:

127.0.0.1        foobar

There’s probably something wrong with the session while using Apache and localhost as a domain. If anyone can elaborate in the comments I’d be happy to edit this answer to include more details.

answered Aug 8, 2019 at 11:53

Teo.sk's user avatar

Teo.skTeo.sk

2,6095 gold badges24 silver badges30 bronze badges

In case you don’t want to use form_row or form_rest and just want to access value of the _token in your twig template. Use the following:

<input type="hidden" name="form[_token]" value="{{ form._token.vars.value }}" />

answered Jun 24, 2014 at 9:13

Imran Zahoor's user avatar

Imran ZahoorImran Zahoor

2,4451 gold badge28 silver badges37 bronze badges

1

In my case I got a trouble with the maxSize annotation in the entity, so I increased it from 2048 to 20048.

 /**
 * @AssertFile(
 *     maxSize = "20048k",
 *     mimeTypes = {"application/pdf", "application/x-pdf"},
 *     mimeTypesMessage = "Please upload a valid PDF"
 * )
 */
private $file;

hope this answer helps!

answered Apr 6, 2016 at 21:42

Jorgeeadan's user avatar

JorgeeadanJorgeeadan

33410 silver badges19 bronze badges

I faced a similar issue. After ensuring the token field was actually rendered (see accepted answer) I checked my cookies.
There were 2(!) cookies for the domain in my Chrome browser, apparently because I was running the application on the same domain as another app, but with a different port (i.e. mydomain.com set the original cookie while the buggy app was running on mydomain.com:123)
Now apparently Chrome sent the wrong cookie so the CSRF protection was unable to link the token to the correct session.

Fix: clear all the cookies for the domain in question, make sure you don’t run multiple applications on the same domain with differing ports.

answered Feb 21, 2018 at 19:12

lkoell's user avatar

I had the same error, but in my case the problem was that my application was using multiple first-level domains, while the cookie was using one. Removing cookie_domain: ".%domain%" from framework.session in the config.yml caused cookies to default to whatever domain the form was on, and that fixed the problem.

answered Mar 25, 2018 at 22:01

ACJ's user avatar

ACJACJ

2,4393 gold badges22 silver badges27 bronze badges

You need to remember that CSRF token is stored in the session, so this problem can also occur due to invalid session handling. If you’re working on the localhost, check e.g. if session cookie domain is set correctly (in PHP it should be empty when on localhost).

answered Jun 30, 2020 at 9:02

Intol's user avatar

This seems to be an issue when using bootstrap unless you are rendering the form by {{ form(form)}}. In addition, the issues seems to only occur on input type=»hidden». If you inspect the page the with the form, you’ll find that the hidden input is not part of the markup at all or it’s being rendered but not submitted for some reason. As suggested above, adding {{form_rest(form)}} or wrapping the input like below should do the trick.

<div class="form-group">
    <input type="hidden" name="_csrf_token" value="{{ csrf_token('authenticate') }}">
</div>

answered Feb 3, 2016 at 21:08

krompir's user avatar

0

Если вы столкнулись с ошибкой «истек CSRF-токен» — читайте нашу статью. Из неё вы узнаете, как работает CSRF-token защита, и что делать, если CSRF токен истек.


Ошибка токен истек 1

Что такое CSRF

CSRF (англ. cross-site request forgery) — это межсайтовая подделка запроса. Это атака, которой может подвергаться любой веб-ресурс или веб-приложение. В первую очередь это касается сайтов, которые используют cookies, сертификаты авторизации и браузерную аутентификацию. В результате атаки страдают клиенты и репутация ресурса.

Вредоносный скрипт прячется в коде сайта или обычной ссылке. С помощью него мошенник получает доступ к конфиденциальной информации: платежным реквизитам, логину и паролю, личной переписке. После того как данные “в кармане”, хакер может изменить пароль, указать свой номер телефона или email, перевести деньги на свой счёт и многое другое.

Как работает CSRF-атака

Злоумышленник может использовать фишинговую ссылку — это наиболее распространенный способ обмана. В этом случае атака работает по следующей схеме:

  1. Злоумышленник создаёт поддельную страницу, очень похожую на оригинальную, и встраивает её в сайт. В коде ссылка может выглядеть так: <a href=“вредоносная ссылка”>Unsubscribe here</a>.
  2. Пользователь переходит с одной страницы сайта на другую (например, на страницу оплаты) и вместо реальной страницы попадает на поддельную.
  3. Пользователь совершает действие на странице, например, оплачивает товар или вводит данные авторизации.
  4. Информация или денежные средства вместо оригинального сервера уходят на сервер мошенника.

CSRF-атаки случаются из-за того, что без специальных настроек сервер не может с точностью в 100% определить, кто именно выполняет действия со стороны пользователя. Он не может проверить, действительно ли на кнопку “оплатить” нажал тот пользователь, который изначально открыл страницу с оплатой. Хакеры активно используют этот люфт в безопасности HTTP-запросов и применяют вредоносные скрипты. Однако от атаки можно защититься с помощью CSRF-токенов. 

Что такое CSRF-token и как он работает

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

CSRF-token — это максимально простой и результативный способ защиты сайта от CSRF-мошенников. Он работает так: сервер создаёт случайный ключ (он же токен) и отправляет его браузеру клиента. Когда браузер запрашивает у сервера информацию, сервер, прежде чем дать ответ, требует показать ключ и проверяет его достоверность. Если токен совпадает, сессия продолжается, а если нет — прерывается. Токен действителен только одну сессию — с новой сессией он обновляется.

Чтобы получить ответ от сервера, используются разные методы запроса. Условно они делятся на две категории: те, которые не изменяют состояние сервера (GET, TRACE, HEAD), и те, которые изменяют (PUT, PATCH, POST и DELETE). Последние имеют большую CSRF-уязвимость и поэтому должны быть защищены в первую очередь.

При создании и использовании токена должны соблюдаться следующие условия:

  • нахождение в скрытом параметре;

  • генерация с помощью генератора псевдослучайных чисел;

  • ограниченное время жизни (одна сессия);

  • уникальность для каждой транзакции;

  • устойчивый к подбору размер (в битах);

  • невозможно переиспользовать.

Типы токенов

Существует три основных типа токенов по способу генерации:

  1. Synchronizer Tokens или Anti-CSRF (токены синхронизации). В этом случае инициатором ключа выступает сервер — на нём хранится исходная шифровка. Когда браузер обращается к серверу и предъявляет ему ключ, сервер сравнивает его с исходником и в зависимости от результата продолжает или прерывает сессию.
  2. Double Submit Cookie (двойная отправка куки). При этом способе токен нигде не хранится. Когда браузер обращается к серверу впервые за сессию, сервер генерирует и передаёт ему ключ в двух формах: через куки и в одном из параметров ответа. При следующих обращениях браузера сервер дважды проверяет правильность ключа — в параметрах и в куках.
  3. Encrypted Token (зашифрованный токен). Этот способ предполагает, что ключом шифруется какая-то часть информации о клиенте, которая содержится в браузере. При первом запросе браузера сервер получает информацию о пользователе, зашифровывает её и передаёт браузеру токен. При следующем взаимодействии сервер расшифровывает токен и сверяет информацию.

Помимо токенов, для защиты используется флаг Same-Site (большинство браузеров его поддерживает). Он работает напрямую для cookies и позволяет помечать куки конкретного домена. Сервер проверяет, содержатся ли нужные пометки в куках страницы, с которых происходит оплата или вносятся изменения. Если пометок нет — сессия прекращается.

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

«Истек срок действия токена» или «CSRF-значение недопустимо»: что это значит и что делать

Даже при авторизации на сайтах, для которых настроена защита от атак, можно встретить следующие варианты сообщения об ошибке: «Недопустимое CSRF-значение»/«CSRF-токены не совпадают» или «Token expired» (в переводе — срок действия токена истек). Сообщение может отображаться как на английском, так и на русском. Пример ошибки при авторизации на сайте REG.RU:



Ошибка токен истек 2

Обычно ошибка возникает по двум основным причинам:

  • сервер некорректно сгенерировал токен;

  • срок токена истек — пользователь долго не совершал никаких действий на странице.

В обоих случаях исправить проблему поможет перезагрузка страницы — вы запустите новую сессию, а значит, сервер и браузер договорятся о новом рабочем токене. Для этого нажмите на значок обновления страницы:


Ошибка токен истек 3

Иногда ошибка возникает из-за расширений защиты конфиденциальности или плагинов блокировки рекламы (например, Ghostery, UBlock Origin, Blur), которые настроены у пользователя. В этом случае можно отключить расширение. Также можно добавить сайт, на котором появилось сообщение, в список доверенных сайтов.

На примере сайта reg.ru покажем, что для этого нужно:

в Google Chrome

  1. Откройте настройки Chrome:

    Ошибка токен истек 4

  2. В списке слева выберите Конфиденциальность и безопасность, а затем Файлы cookie и другие данные сайтов.
  3. Внизу страницы откройте Сайты, которые всегда могут использовать файлы cookie и кликните Добавить.
  4. Введите «[*.]www.reg.ru» и нажмите Добавить.
  5. Нажмите Все файлы cookie и данные сайта и удалите все записи, которые связаны с сайтом reg.ru.
  6. Перезагрузите браузер и выполните операцию повторно.

в Яндекс.Браузер

  1. Откройте настройки браузера Яндекс:

    20220125_chto_oznachayet_oshibka_csrf_token_istek_5.png

  2. Перейдите на Сайты Расширенные.
  3. Кликните Настройки… для первого параметра в списке. Затем на вкладке «Разрешена» введите www.reg.ru и кликните Добавить.
  4. Добавьте адрес сайта для всех параметров списка по аналогии.

в Safari

  1. Откройте настройки Safari комбинацией Cmd + , (⌘,).
  2. Перейдите на вкладку Конфиденциальность и проверьте, что в пункте «Файлы cookie и данные веб-сайтов» не выбрано «Блокировать все файлы cookie». Если это так, снимите настройки.
  3. Кликните Управление данными веб-сайтов и удалите все записи, которые относятся к www.reg.ru.
  4. Перезагрузите браузер и выполните операцию повторно.

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

Заключение

Успешная атака CSRF позволяет хакеру действовать на сайте от имени другого зарегистрированного посетителя. Чтобы мошенник не добрался до конфиденциальных данных, для сайта нужно настроить один из типов CSRF-токенов. Токены позволяют серверу и браузеру безопасно обмениваться информацией в течение сессии. Однако даже на безопасных сайтах можно столкнуться с ошибкой «токен CSRF истек». В этом нет ничего страшного. Чтобы возобновить подключение, достаточно обновить страницу браузера.

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:

<form novalidate action="{{path('signup_index')}}" method="post" {{form_enctype(form)}} role="form" class="form-horizontal">
    <div class="form-group">
        {{ form_label(form.email, 'Email', {'label_attr': {'class': 'col-md-1 control-label'}}) }}
        {{ form_widget(form.email, {'attr': {'class': 'col-md-2'}}) }}
        {{ form_errors(form.email) }}
    </div>

    <div class="form-group">
        {{ form_label(form.nickname, 'Nickname', {'label_attr': {'class': 'col-md-1 control-label'}}) }}
        {{ form_widget(form.nickname, {'attr':{'class': 'col-md-2'}}) }}
        {{ form_errors(form.nickname, {'attr': {'class': 'col-md-3'}}) }}
    </div>
    <div class="form-group">
        {{ form_label(form.password, 'password', {'label_attr': {'class': 'col-md-1 control-label'}}) }}
        {{ form_widget(form.password, {'attr': {'class': 'col-md-2'}}) }}
        {{ form_errors(form.password, {'attr': {'class': 'col-md-3'}}) }}
    </div>

    <div class="form-group">
        {{ form_label(form.password_repeat, 'Repeat password', {'label_attr': {'class': 'col-md-1 control-label'}}) }}
        {{ form_widget(form.password_repeat, {'attr':{'class': 'col-md-2'}}) }}
        {{ form_errors(form.password_repeat, {'attr': {'class': 'col-md-3'}}) }}
    </div>
    <div class="form-group">
        <div class="col-md-1 control-label">
        <input type="submit" value="submit">
    </div>

    </div>
</form>

Any ideas?

Don't Panic's user avatar

Don’t Panic

40.8k10 gold badges61 silver badges78 bronze badges

asked May 4, 2014 at 11:38

Francisco Albert's user avatar

Francisco AlbertFrancisco Albert

1,5472 gold badges17 silver badges32 bronze badges

1

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

{{ form_row(form._token) }}

As of now your form is missing the CSRF token field. If you use the twig form functions to render your form like form(form) this will automatically render the CSRF token field for you, but your code shows you are rendering your form with raw HTML like <form></form>, so you have to manually render the field.

Or, simply add {{ form_rest(form) }} before the closing tag of the form.

According to docs

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).

form_rest(view, variables)

Community's user avatar

answered May 4, 2014 at 11:41

M Khalid Junaid's user avatar

M Khalid JunaidM Khalid Junaid

63.3k10 gold badges90 silver badges116 bronze badges

4

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

This option in php.ini cause of problem

; How many GET/POST/COOKIE input variables may be accepted
 max_input_vars = 1000

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

Also, it concerns a big files. Increasing the

upload_max_filesize

option will solve problem.

answered Nov 5, 2014 at 20:39

zalex's user avatar

4

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:

// Other methods omitted

public function getDefaultOptions(array $options)
{
    return array(
        'csrf_protection' => false,
        // Rest of options omitted
    );
}

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 novalidate action="{{path('signup_index')}}" method="post" {{form_enctype(form)}} role="form" class="form-horizontal">
    <!-- Code omitted -->

    <div class="form-group">
        <div class="col-md-1 control-label">
            <input type="submit" value="submit">
        </div>

    </div>
    {{ form_rest(form) }}
</form>

{{ form_rest(form) }} renders all fields which you haven’t entered manually.

answered May 4, 2014 at 20:09

2

Before your </form> tag put:

{{ form_rest(form) }}

It will automatically insert other important (hidden) inputs.

answered May 4, 2014 at 11:46

Lkopo's user avatar

LkopoLkopo

4,7588 gold badges34 silver badges60 bronze badges

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.

answered Mar 31, 2017 at 13:27

Benoit Duffez's user avatar

Benoit DuffezBenoit Duffez

11.5k12 gold badges74 silver badges123 bronze badges

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.

session_prefix: 'My Website'

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

answered Jan 18, 2017 at 3:49

Henry's user avatar

HenryHenry

7,6112 gold badges38 silver badges38 bronze badges

1

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

When I got this error, I couldn’t figure it out at first. I’m using form_start() and form_end() to generate the form, so I shouldn’t have to explicitly add the token with form_row(form._token), or use form_rest() to get it. It should have already been added automatically by form_end().

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 </form> tag, so instead of :

{{ form_end(form) }}

I had:

</form>
{{ form_end(form) }}

That actually seems like something that might throw an error, but apparently it doesn’t, so when form_end() outputs form_rest(), the form is already closed. The actual generated page source of the form was like this:

<form>
    <!-- all my form fields... -->
</form>
<input type="hidden" id="item__token" name="item[_token]" value="SQAOs1xIAL8REI0evGMjOsatLbo6uDzqBjVFfyD0PE4" />
</form>

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

answered Mar 12, 2017 at 19:09

Don't Panic's user avatar

Don’t PanicDon’t Panic

40.8k10 gold badges61 silver badges78 bronze badges

I had this error recently. Turns out that my cookie settings were incorrect in config.yml. Adding the cookie_path and cookie_domain settings to framework.session fixed it.

answered Jun 1, 2017 at 19:20

Michael's user avatar

MichaelMichael

8,4444 gold badges26 silver badges36 bronze badges

I hade the same issue recently, and my case was something that’s not mentioned here yet:

The problem was I was testing it on localhost domain. I’m not sure why exactly was this an issue, but it started to work after I added a host name alias for localhost into /etc/hosts like this:

127.0.0.1        foobar

There’s probably something wrong with the session while using Apache and localhost as a domain. If anyone can elaborate in the comments I’d be happy to edit this answer to include more details.

answered Aug 8, 2019 at 11:53

Teo.sk's user avatar

Teo.skTeo.sk

2,6095 gold badges24 silver badges30 bronze badges

In case you don’t want to use form_row or form_rest and just want to access value of the _token in your twig template. Use the following:

<input type="hidden" name="form[_token]" value="{{ form._token.vars.value }}" />

answered Jun 24, 2014 at 9:13

Imran Zahoor's user avatar

Imran ZahoorImran Zahoor

2,4451 gold badge28 silver badges37 bronze badges

1

In my case I got a trouble with the maxSize annotation in the entity, so I increased it from 2048 to 20048.

 /**
 * @AssertFile(
 *     maxSize = "20048k",
 *     mimeTypes = {"application/pdf", "application/x-pdf"},
 *     mimeTypesMessage = "Please upload a valid PDF"
 * )
 */
private $file;

hope this answer helps!

answered Apr 6, 2016 at 21:42

Jorgeeadan's user avatar

JorgeeadanJorgeeadan

33410 silver badges19 bronze badges

I faced a similar issue. After ensuring the token field was actually rendered (see accepted answer) I checked my cookies.
There were 2(!) cookies for the domain in my Chrome browser, apparently because I was running the application on the same domain as another app, but with a different port (i.e. mydomain.com set the original cookie while the buggy app was running on mydomain.com:123)
Now apparently Chrome sent the wrong cookie so the CSRF protection was unable to link the token to the correct session.

Fix: clear all the cookies for the domain in question, make sure you don’t run multiple applications on the same domain with differing ports.

answered Feb 21, 2018 at 19:12

lkoell's user avatar

I had the same error, but in my case the problem was that my application was using multiple first-level domains, while the cookie was using one. Removing cookie_domain: ".%domain%" from framework.session in the config.yml caused cookies to default to whatever domain the form was on, and that fixed the problem.

answered Mar 25, 2018 at 22:01

ACJ's user avatar

ACJACJ

2,4393 gold badges22 silver badges27 bronze badges

You need to remember that CSRF token is stored in the session, so this problem can also occur due to invalid session handling. If you’re working on the localhost, check e.g. if session cookie domain is set correctly (in PHP it should be empty when on localhost).

answered Jun 30, 2020 at 9:02

Intol's user avatar

This seems to be an issue when using bootstrap unless you are rendering the form by {{ form(form)}}. In addition, the issues seems to only occur on input type=»hidden». If you inspect the page the with the form, you’ll find that the hidden input is not part of the markup at all or it’s being rendered but not submitted for some reason. As suggested above, adding {{form_rest(form)}} or wrapping the input like below should do the trick.

<div class="form-group">
    <input type="hidden" name="_csrf_token" value="{{ csrf_token('authenticate') }}">
</div>

answered Feb 3, 2016 at 21:08

krompir's user avatar

0

How to fix the “CSRF token mismatch error” message

Diana avatar

Written by Diana

Updated over a week ago

Errors are a tiny but inevitable part of one’s web experience, no matter how secure and trusted a platform is. Luckily, there are always ways to bypass them without any ifs, ands and buts.

Here’s a brief cheat sheet of avoiding the «CSRF token mismatch error» message you might get while creating your website or crafting a logo with our Logo Maker.

What’s CSRF?

Cross-Site Request Forgery is an attack that forces the user to execute unwanted actions on a website during state-changing requests.

The “Invalid or missing CSRF token” message means that your browser couldn’t create a secure cookie or couldn’t access that cookie to authorize your login. This can be caused by ad- or script-blocking plugins or extensions and the browser itself if it’s not allowed to set cookies.

It’s completely harmless on Ucraft and sometimes all you need to do is refresh your page, and you’re all set to continue your job.

If this doesn’t help, there are ways to fix this on different browsers.

Safari

  1. Open Safari Preferences from the drop-down menu in the upper right corner or through Cmd + comma (⌘+,) shortcut.

  2. Click the Privacy tab and make sure that «Cookies and website data» is set to either «Always allow» or «Allow from websites I visit.»

  3. Click on the Manage Website Data button to see all locally stored website data.

  4. Search for “Ucraft” and remove all Ucraft-related entries.

  5. Reload Safari and check Ucraft.

Chrome

  1. Open Chrome Settings.

  2. Scroll to the bottom and click on Advanced.

  3. In the Privacy and Security section, click the Content Settings button.

  4. Click on Cookies.

  5. Next to Allow, click Add. Type [*.]ucraft.com and click “Add.”

  6. Under All cookies and site data, search for Ucraft, and delete all Ucraft-related entries.

  7. Reload Chrome and log into Ucraft.

Firefox

  1. Go to Firefox’s Preferences > Privacy & Security Menu.

  2. In the History section, select «Use custom settings for history» from the drop-down menu.

  3. Click on Exceptions and whitelist ucraft.com.

  4. Scroll down to Site Data and click on Settings next to it.

  5. Search for «Ucraft» and remove all shown entries.

  6. Reload Firefox and try to log in.

* Note, if this alone won’t help, please enable third-party cookies from the menu above.

You’re all set now!

Have more questions while dealing with errors? Don’t hesitate to contact us via the live chat box in the lower right corner and ask right away.

Likewise, if you are looking to build a new website for your business, we’re always here to help you create your own website or online store with Ucraft.

CSRF Protection Problem and How to Fix it

One day I was working on a feature at work. I had many branches created in JIRA tickets, so I wanted to open a bunch of PRs (Pull Requests) all at once in different tabs.

This is how I usually work – I have a lot of tabs open and this speeds things up, because I don’t need to wait for the next page to load.

But after I’d created the first PR in BitBucket and tried to go on to the next page, I was welcomed with an error message about an invalid CSRF token. This is a common problem with web applications that have CSRF protection.

So in this article you’ll learn what CSRF is and how to fix this error.

Table of contents:

  • What is CSRF?
  • Standard CSRF protection
  • The Problem with Tokens
  • Cross-tab Communication Solution
    • Sysend library
    • Broadcast Channel
  • Conclusion

What is CSRF?

CSRF is an acronym for Cross-Site Request Forgery. It is a vector of attack that attackers commonly use to get into your system.

The way you usually protect against CSRF is to send a unique token generated by each HTTP request. If the token that is on the server doesn’t match with the one from the request, you show an error to the user.

Standard CSRF protection

This is one way you can protect against CSRF with a token:

const inital_token = '...';

const secure_fetch = (token => {
    const CSRF_HEADER = 'X-CSRF-TOKEN';
    return (url) => {
        const response = await fetch(url, {
            method: 'POST',
            headers: {
              [CSRF_HEADER]: token
            }
        });
        response.then(res => {
           token = res.headers[CSRF_HEADER]
        });
        return response;
    };
})(inital_token);

This code uses the fetch API to send and receive a secure token in HTTP headers. On the backed, you should generate the first initial token when the page loads. On the server, on each AJAX request, you should check to see if the token is valid.

The Problem with Tokens

This works fine unless you have more than one tab open. Each tab can send requests to the server, which will break this solution. And power users may not be able to use your application the way they want.

But there is a simple solution to this problem which is cross-tab communication.

Cross-tab Communication Solution

Sysend library

You can use the Sysend library, an open source solution that I’ve created specifically for this purpose. It simplifies cross-tabs communication.

If you want, you can use a native browser API like Broadcast Channel to do the same. More on how to do that later in this article.

But the Sysend library will work for browsers that don’t support Broadcast Channel. It also works in IE (it has some bugs, which is not a surprise). You may also need to support some old mobile browsers. It also has a much simpler API.

This is the simplest example:

let token;
sysend.on('token', new_token => {
    token = new_token;
});

// ...

sysend.broadcast('token', token);
Simple example of using base function of sysend library

And this is how you would use this library to fix CSRF protection:

const inital_token = '...';

const secure_fetch = (token => {
    const CSRF_HEADER = 'X-CSRF-TOKEN';
    const EVENT_NAME = 'csrf';
    sysend.on(EVENT_NAME, new_token => {
        // get new toke from different tab
        token = new_token;
    });
    return (url) => {
        const response = await fetch(url, {
            method: 'POST',
            headers: {
              [CSRF_HEADER]: token
            }
        });
        response.then(res => {
           token = res.headers[CSRF_HEADER];
           // send new toke to other tabs
           sysend.broadcast(EVENT_NAME, token); 
        });
        return response;
    };
})(inital_token);
secure_fetch function with CSRF protection using sysend

All you have to do is to send and receive a single message from other tabs when sending the request. And your CSRF protected app will work on many tabs.

And that’s it. This will let advanced users use your app that has CSRF protection when they want to open many tabs.

Broadcast Channel

Here is the simplest possible example of using Broadcast Channel:

const channel = new BroadcastChannel('my-connection');
channel.addEventListener('message', (e) => {
    console.log(e.data); // 'some message'
});
channel.postMessage('some message');
Basic usage of Broadcast Channel

So with this simple API you can do the same thing that we did before:

const inital_token = '...';

const secure_fetch = (token => {
    const CSRF_HEADER = 'X-CSRF-TOKEN';
    const channel = new BroadcastChannel('csrf-protection');
    channel.addEventListener('message', (e) => {
        // get new toke from different tab
    	token = e.data;
    });
    return (url) => {
        const response = await fetch(url, {
            method: 'POST',
            headers: {
              [CSRF_HEADER]: token
            }
        });
        response.then(res => {
           token = res.headers[CSRF_HEADER];
           // send new token to other tabs
           channel.postMessage(token);
        });
        return response;
    };
})(inital_token);
secure_fetch function with CSRF protection using BroadcastChannel

As you can see from the above example, Broadcast Channel doesn’t have any namespace for events. So if you want to send more than one type of event you need to create types of events.

Here is an example of using Broadcast Channel to do more than the CSRF protection fix we’ve discussed so far.

You can synchronize login and logout for your application. If you login into one tab, your other tabs will also sign you in. In the same way, you can synchronize the shopping cart in some e-commerce websites.

const channel = new BroadcastChannel('my-connection');
const CSRF = 'app/csrf';
const LOGIN = 'app/login';
const LOGOUT = 'app/logout';
let token;
channel.addEventListener('message', (e) => {
    switch (e.data.type) {
        case CSRF:
            token = e.data.payload;
            break;
        case LOGIN:
            const { user } = e.data.payload;
            autologin(user);
            break;
        case LOGOUT:
            logout();
            break;
    }
});

channel.postMessage({type: 'login', payload: { user } });
Using Broadcast Channel with different type of messages

Conclusion

It’s great if you protect your app against attackers. But keep in mind how people will be using your application, too so you don’t make it unnecessarily hard to use. This applies not only to this particular problem.

The Sysend library is a simple way to communicate between open tabs in the same browser. And it can fix major issues with CSRF protection. The library has more features, and you can check its GitHub repo for more details.

Broadcast Channel is also not that complicated. If you don’t need to support old browsers or some older mobile devices, you can use this API. But if you need to support older browsers, or want to make your code simpler, you use can the sysend library.

If you want to see browser support for Broadcast Channel, you can see Can I Use.



Learn to code for free. freeCodeCamp’s open source curriculum has helped more than 40,000 people get jobs as developers. Get started

Содержание

  1. Forbidden — CSRF token invalid #93
  2. Comments
  3. Keep getting: Forbidden — CSRF token invalid — using example #30
  4. Comments
  5. Forbidden error invalid csrf token
  6. We use cookies on this site to enhance your user experience
  7. Что означает ошибка «CSRF токен истек»
  8. Что такое CSRF
  9. Как работает CSRF-атака
  10. Что такое CSRF-token и как он работает
  11. Типы токенов
  12. «Истек срок действия токена» или «CSRF-значение недопустимо»: что это значит и что делать
  13. Заключение

Forbidden — CSRF token invalid #93

Hi
can you please help I’m always getting the error «Forbidden — CSRF token invalid» even though I have disabled the secure flag my code is below

my request headers are below:
Accept: text/html, /; q=0.01
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,ar;q=0.8
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 198
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: _gorilla_csrf=MTUyOTgzMzU5M3xJbmR2VkhRMWJrbEhVV3hhUlU1b2F5dFZOMkpLY0dsUmMyRTBOMjFRT0ZoM1kyMHhWSEJuV0ZOSFNUZzlJZ289fMv0K_iHYrxTr7pjDC6J5uZpxWjltzhssQhv8TCZ3duI
Host: localhost:8080
Origin: http://localhost:8080
Pragma: no-cache
Referer: http://localhost:8080/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
X-CSRF-Token: MTUyOTgzMzU5M3xJbmR2VkhRMWJrbEhVV3hhUlU1b2F5dFZOMkpLY0dsUmMyRTBOMjFRT0ZoM1kyMHhWSEJuV0ZOSFNUZzlJZ289fMv0K_iHYrxTr7pjDC6J5uZpxWjltzhssQhv8TCZ3duI
X-Requested-With: XMLHttpRequest

my form data are below
user: hayder.sinan
pass: *************
authenticity_token: MTUyOTgzMzU5M3xJbmR2VkhRMWJrbEhVV3hhUlU1b2F5dFZOMkpLY0dsUmMyRTBOMjFRT0ZoM1kyMHhWSEJuV0ZOSFNUZzlJZ289fMv0K_iHYrxTr7pjDC6J5uZpxWjltzhssQhv8TCZ3duI

can you please help?

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

Источник

Keep getting: Forbidden — CSRF token invalid — using example #30

I must be doing something really wrong but running the example from
http://www.gorillatoolkit.org/pkg/csrf

keeps giving me Forbidden — CSRF token invalid

the only changed I made to the example was to use

in the post request, I see the name, email fields being submitted, and also

I added some logging to

and I see that realToken is always []

I’m running this on http://localhost:8000/ and made sure to delete all cookies between runs in case I was in some kind of bad state

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

of course, after submitting this I found out I needed to make two changes, one was the key, the other was:

it could help to have a note on the docs (I actually found the note on your blog after googling again).

Are you setting csrf.Secure(false) in development? Cookies are only sent
over HTTPS by default.

On Mon, Apr 4, 2016 at 2:59 AM Diego Medina notifications@github.com
wrote:

of course, after submitting this I found out I needed to make two changes,
one was the key, the other was:

it could help to have a note on the docs (I actually found the note on
your blog after googling again).


You are receiving this because you are subscribed to this thread.

Reply to this email directly or view it on GitHub
#30 (comment)

Now that I pass csrf.Secure(false) the sample is working ok (and will make it a flag for dev mode only). Thanks. I’ll close this ticket now

I’ve also just run into this problem, maybe it could be cleared up in the documentation?

This is currrently documented in-line with the example code. Where else
would you like to see it / how can it be made clearer?
On Tue, Aug 30, 2016 at 9:41 AM Wayne Ashley Berry notifications@github.com
wrote:

I’ve also just run into this problem, maybe it could be cleared up in the
documentation?

I see it on the README, which is great, maybe adding it inline to the examples found on http://www.gorillatoolkit.org/pkg/csrf is all that is needed now

Yeah, the readme mentions the use of csrf.Secure(false) in the first example whereas the website only really mentions it under the method documentation.

Added the same comment from the readme to the docs here #44, that would hopefully prevent this from happening again 🙂

Источник

Forbidden error invalid csrf token

While connecting to Activiti from ADF I am getting below error :

Access to the specified resource has been forbidden.

  • Mark as New
  • Bookmark
  • Subscribe
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Report Inappropriate Content

A workaround is to disable CSRF in Activiti. Put this in your activiti-app.properties:

Let me know if this works.

  • Mark as New
  • Bookmark
  • Subscribe
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Report Inappropriate Content

Did you try to switch off the csrf option (top left of the page)?

in case you tried can you share with us what you see in the console log of your browser?

  • Mark as New
  • Bookmark
  • Subscribe
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Report Inappropriate Content

A workaround is to disable CSRF in Activiti. Put this in your activiti-app.properties:

Let me know if this works.

  • Mark as New
  • Bookmark
  • Subscribe
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Report Inappropriate Content

Hi Ole Hejlskov ‌
I am facing exact same issue with APS 1.8.1 and APW 1.3.1

Could you please suggest some check points?

Note: with workaround to disable CSRF, I could login.

Content from pre 2016 and from language groups that have been closed.

Content is read-only.

28 Million Users
1300+ Industry Leading Companies
90% Customer Renewal

We use cookies on this site to enhance your user experience

By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.

Источник

Что означает ошибка «CSRF токен истек»

Если вы столкнулись с ошибкой «истек CSRF-токен» — читайте нашу статью. Из неё вы узнаете, как работает CSRF-token защита, и что делать, если CSRF токен истек.

Что такое CSRF

CSRF (англ. cross-site request forgery) — это межсайтовая подделка запроса. Это атака, которой может подвергаться любой веб-ресурс или веб-приложение. В первую очередь это касается сайтов, которые используют cookies, сертификаты авторизации и браузерную аутентификацию. В результате атаки страдают клиенты и репутация ресурса.

Вредоносный скрипт прячется в коде сайта или обычной ссылке. С помощью него мошенник получает доступ к конфиденциальной информации: платежным реквизитам, логину и паролю, личной переписке. После того как данные “в кармане”, хакер может изменить пароль, указать свой номер телефона или email, перевести деньги на свой счёт и многое другое.

Как работает CSRF-атака

Злоумышленник может использовать фишинговую ссылку — это наиболее распространенный способ обмана. В этом случае атака работает по следующей схеме:

  1. Злоумышленник создаёт поддельную страницу, очень похожую на оригинальную, и встраивает её в сайт. В коде ссылка может выглядеть так: Unsubscribe here.
  2. Пользователь переходит с одной страницы сайта на другую (например, на страницу оплаты) и вместо реальной страницы попадает на поддельную.
  3. Пользователь совершает действие на странице, например, оплачивает товар или вводит данные авторизации.
  4. Информация или денежные средства вместо оригинального сервера уходят на сервер мошенника.

CSRF-атаки случаются из-за того, что без специальных настроек сервер не может с точностью в 100% определить, кто именно выполняет действия со стороны пользователя. Он не может проверить, действительно ли на кнопку “оплатить” нажал тот пользователь, который изначально открыл страницу с оплатой. Хакеры активно используют этот люфт в безопасности HTTP-запросов и применяют вредоносные скрипты. Однако от атаки можно защититься с помощью CSRF-токенов.

Что такое CSRF-token и как он работает

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

CSRF-token — это максимально простой и результативный способ защиты сайта от CSRF-мошенников. Он работает так: сервер создаёт случайный ключ (он же токен) и отправляет его браузеру клиента. Когда браузер запрашивает у сервера информацию, сервер, прежде чем дать ответ, требует показать ключ и проверяет его достоверность. Если токен совпадает, сессия продолжается, а если нет — прерывается. Токен действителен только одну сессию — с новой сессией он обновляется.

Чтобы получить ответ от сервера, используются разные методы запроса. Условно они делятся на две категории: те, которые не изменяют состояние сервера (GET, TRACE, HEAD), и те, которые изменяют (PUT, PATCH, POST и DELETE). Последние имеют большую CSRF-уязвимость и поэтому должны быть защищены в первую очередь.

При создании и использовании токена должны соблюдаться следующие условия:

нахождение в скрытом параметре;

генерация с помощью генератора псевдослучайных чисел;

ограниченное время жизни (одна сессия);

уникальность для каждой транзакции;

устойчивый к подбору размер (в битах);

Типы токенов

Существует три основных типа токенов по способу генерации:

  1. Synchronizer Tokens или Anti-CSRF (токены синхронизации). В этом случае инициатором ключа выступает сервер — на нём хранится исходная шифровка. Когда браузер обращается к серверу и предъявляет ему ключ, сервер сравнивает его с исходником и в зависимости от результата продолжает или прерывает сессию.
  2. Double Submit Cookie (двойная отправка куки). При этом способе токен нигде не хранится. Когда браузер обращается к серверу впервые за сессию, сервер генерирует и передаёт ему ключ в двух формах: через куки и в одном из параметров ответа. При следующих обращениях браузера сервер дважды проверяет правильность ключа — в параметрах и в куках.
  3. Encrypted Token (зашифрованный токен). Этот способ предполагает, что ключом шифруется какая-то часть информации о клиенте, которая содержится в браузере. При первом запросе браузера сервер получает информацию о пользователе, зашифровывает её и передаёт браузеру токен. При следующем взаимодействии сервер расшифровывает токен и сверяет информацию.

Помимо токенов, для защиты используется флаг Same-Site (большинство браузеров его поддерживает). Он работает напрямую для cookies и позволяет помечать куки конкретного домена. Сервер проверяет, содержатся ли нужные пометки в куках страницы, с которых происходит оплата или вносятся изменения. Если пометок нет — сессия прекращается.

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

«Истек срок действия токена» или «CSRF-значение недопустимо»: что это значит и что делать

Даже при авторизации на сайтах, для которых настроена защита от атак, можно встретить следующие варианты сообщения об ошибке: «Недопустимое CSRF-значение»/«CSRF-токены не совпадают» или «Token expired» (в переводе — срок действия токена истек). Сообщение может отображаться как на английском, так и на русском. Пример ошибки при авторизации на сайте REG.RU:

Обычно ошибка возникает по двум основным причинам:

сервер некорректно сгенерировал токен;

срок токена истек — пользователь долго не совершал никаких действий на странице.

В обоих случаях исправить проблему поможет перезагрузка страницы — вы запустите новую сессию, а значит, сервер и браузер договорятся о новом рабочем токене. Для этого нажмите на значок обновления страницы:

Иногда ошибка возникает из-за расширений защиты конфиденциальности или плагинов блокировки рекламы (например, Ghostery, UBlock Origin, Blur), которые настроены у пользователя. В этом случае можно отключить расширение. Также можно добавить сайт, на котором появилось сообщение, в список доверенных сайтов.

На примере сайта reg.ru покажем, что для этого нужно:

  1. Откройте настройки Chrome:
  2. В списке слева выберите Конфиденциальность и безопасность, а затем Файлы cookie и другие данные сайтов.
  3. Внизу страницы откройте Сайты, которые всегда могут использовать файлы cookie и кликните Добавить.
  4. Введите «[*.]www.reg.ru» и нажмите Добавить.
  5. Нажмите Все файлы cookie и данные сайта и удалите все записи, которые связаны с сайтом reg.ru.
  6. Перезагрузите браузер и выполните операцию повторно.
  1. Откройте настройки браузера Яндекс:
  2. Перейдите на СайтыРасширенные.
  3. Кликните Настройки… для первого параметра в списке. Затем на вкладке «Разрешена» введите www.reg.ruи кликните Добавить.
  4. Добавьте адрес сайта для всех параметров списка по аналогии.
  1. Откройте настройки Safari комбинацией Cmd + , (⌘,).
  2. Перейдите на вкладку Конфиденциальность и проверьте, что в пункте «Файлы cookie и данные веб-сайтов» не выбрано «Блокировать все файлы cookie». Если это так, снимите настройки.
  3. Кликните Управление данными веб-сайтов и удалите все записи, которые относятся к www.reg.ru.
  4. Перезагрузите браузер и выполните операцию повторно.

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

Заключение

Успешная атака CSRF позволяет хакеру действовать на сайте от имени другого зарегистрированного посетителя. Чтобы мошенник не добрался до конфиденциальных данных, для сайта нужно настроить один из типов CSRF-токенов. Токены позволяют серверу и браузеру безопасно обмениваться информацией в течение сессии. Однако даже на безопасных сайтах можно столкнуться с ошибкой «токен CSRF истек». В этом нет ничего страшного. Чтобы возобновить подключение, достаточно обновить страницу браузера.

Источник

Иногда при попытке войти в свою учетную запись Todoist вы сталкиваетесь с ошибкой токена CSRF. Когда это происходит, вы не можете войти в свой профиль. Это может произойти по двум основным причинам. Во-первых, используемый вами браузер не может создавать безопасные файлы cookie. Во-вторых, он не может получить доступ к cookie для авторизации вашего входа в систему. Следовательно, вы видите сообщение об ошибке: токен CSRF отсутствует или недействителен.

Могут быть и другие причины, такие как плагин блокировки рекламы или блокировщик скриптов. Если вы используете какие-либо такие расширения в своем браузере, возможно, вы столкнетесь с этой ошибкой при попытке войти в свою учетную запись Todoist. В этом руководстве я описал несколько механизмов устранения неполадок, которые позволят вам исправить ошибку токена CSRF во всех основных веб-браузерах.

Todoist

Содержание

  • 1 Исправить ошибку токена Todoist CSRF

    • 1.1 Браузер Firefox
    • 1.2 Браузер Chrome
    • 1.3 Исправить ошибку токена CSRF в браузере Safari
    • 1.4 Решить проблему несоответствия токенов

Исправить ошибку токена Todoist CSRF

Я изложил шаги по исправлению ошибки токена CSRF для веб-браузеров Firefox, Chrome и Safari. Следуйте руководству в зависимости от того, какой браузер вы используете на своем ПК / ноутбуке.

Браузер Firefox

  • Запустите браузер Firefox
  • Нажми на кнопка гамбургера с правой стороны
  • Затем нажмите на Параметры
  • Затем на левой панели нажмите на Безопасность
  • Теперь нажмите на Исключения
  • Добавить https: // todoist.com 
  • еще раз добавить https://cloudfront.net
  • Затем нажмите Сохранить изменения
  • Теперь нажмите Управление данными > поиск Todoist
  • Выбрать Удалить все показанные вариант
  • Нажмите на Сохранить изменения
  • Во всплывающем окне нажмите удалять
  • После завершения перезапустите Firefox.
  • Теперь войдите в Todoist

Браузер Chrome

Исправить ошибку токена CSRF в браузере Safari

  • Запустите браузер Safari
  • из раскрывающегося меню откройте Настройки Safari на панели навигации
  • Нажмите на Конфиденциальность > Вариант Файлы cookie и данные веб-сайтов установлен на Всегда позволяют или Разрешить с веб-сайтов, которые я посещаю
  • Затем нажмите на Управление данными веб-сайта. Это покажет вам данные веб-сайта, хранящиеся локально.
  • Искать Todoist
  • Удалите все записи, в которых упоминается Todoist.
  • Закройте и повторно запустите Safari.
  • Войдите в аккаунт Todoist

Решить проблему несоответствия токенов

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

Итак, вот и все о том, как исправить ошибку токена CSRF, возникающую при доступе к вашей учетной записи Todoist. Я надеюсь, что это руководство поможет вам.

Другие руководства,

  • Как подключить Google Диск и Dropbox к Todoist
  • Dropbox против Google Drive: какое облачное хранилище лучше
  • Как исправить: ошибка Google Диска при создании копии

Сваям — профессиональный технический блоггер со степенью магистра компьютерных приложений, а также имеет опыт разработки под Android. Он убежденный поклонник Stock Android OS. Помимо технических блогов, он любит игры, путешествовать и играть на гитаре.

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

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

Список ошибок:
1) Полностью отсутствует защита от CSRF.

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

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

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

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

Казалось бы, очень удобно использовать HTTP referer (https://ru.wikipedia.org/wiki/HTTP_referer) для защиты от атак. Если в этом заголовке не страницы с вашего домена, то запрос был подделан. Но не все так радужно. У небольшой части пользователей HTTP referer может быть пуст по разным причинам. Кроме того, он может быть подделан с использованием старых версий Flash, что подставляет под удар тех, кто очень долго ничего не обновлял на своем компьютере.

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

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

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-атак стоит достаточно остро. Безусловно, этот список не является исчерпывающим. Я уверен, что можно найти еще несколько ошибок и способов их эксплуатации. Однако если вы проверите свои сайты на наличие проблем, описанных в этой статье, и исправите их, то значительно повысите защищенность проекта.

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

Я получаю это сообщение об ошибке каждый раз, когда я пытаюсь представить форме:

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

13 ответов

вам нужно добавить _token в форме я.е

на данный момент в вашей форме отсутствует поле токена CSRF. Если вы используете функции формы веточки для отображения вашей формы, как form(form) это автоматически отобразит поле токена CSRF для вас, но ваш код показывает, что вы визуализируете свою форму с raw HTML, как <form></form> , поэтому вам нужно вручную отобразить поле.

или просто добавьте > перед закрывающим тегом формы.

согласно docs

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

Также вы можете увидеть это сообщение об ошибке, если ваша форма имеет много элементов.

эта опция в php.ini причина проблемы

проблема в том, что _token пропускает запрос PUT (GET) Таким образом, вы можете увеличить стоимость.

кроме того, это касается больших файлов. Увеличение

опция решит проблему

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

вы можете отключить эту защиту CSRF в своем классе формы в getDefaultOptions способ такой:

если вы не хотите отключать защиту CSRF, вам нужно отобразить поле защиты CSRF в вашей форме. Это можно сделать с помощью > в вашем файле представления, например:

> отображает все поля, которые вы не ввели вручную.

перед </form> tag put:

он автоматически вставит другие важные (скрытые) входы.

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

в недавнем случае мой коллега изменил «session_prefix» на значение, в котором было пробел.

это сломанное хранилище сеансов, что, в свою очередь, означало, что моя форма не смогла получить токен CSRF из сеанса.

У меня была эта проблема со странным поведением: очистка кэша браузера не исправила ее, но Очистка файлов cookie (то есть файла cookie идентификатора сеанса PHP) решила проблему.

Это должно быть сделано после вы проверили все другие ответы, включая проверку вас do имейте токен в скрытом поле ввода формы.

недавно у меня была эта ошибка. Оказывается, Мои настройки cookie были неправильными в config.в формате YML. Добавление cookie_path и cookie_domain параметры framework.session исправил.

Если вы не хотите использовать form_row или form_rest и просто хотите получить доступ к значению _token в шаблоне twig. Используйте следующее:

в моем случае у меня возникли проблемы с аннотацией maxSize в сущности, поэтому я увеличил ее с 2048 до 20048.

надеюсь, что этот ответ поможет!

если вы преобразовали свою форму из простого HTML в twig, убедитесь, что вы не пропустили удаление закрытия </form> — тег. Глупая ошибка, но как я обнаружил, это возможная причина этой проблемы.

когда я получил эту ошибку, я не мог понять сначала. Я использую form_start() и form_end() для генерации формы, поэтому я не нужно явно добавлять маркер С form_row(form._token) , или использовать form_rest() чтобы получить его. он уже должен был быть добавлен автоматически form_end() .

проблема заключалась в том, что представление, с которым я работал, было преобразовано из простого HTML в twig, и я пропустил удаление закрытия </form> — тег, поэтому вместо :

это на самом деле похоже на то, что может вызвать ошибку, но, по-видимому, это не так, поэтому когда form_end() выходы form_rest() , форма уже закрыта. Фактический сгенерированный источник страницы формы был похож это:

очевидно, решение удалить лишний закрывающий тег и может выпить еще кофе.

Я столкнулся с аналогичной проблемой. После того, как поле токена было фактически отображено (см. принятый ответ), я проверил свои куки. Было 2(!) cookies для домена в моем браузере Chrome, по-видимому, потому, что я запускал приложение в том же домене, что и другое приложение, но с другим портом (т. е. mydomain.com установите исходный файл cookie, пока приложение buggy работает на mydomain.com: 123) Теперь, по-видимому, Chrome отправил неправильный cookie, поэтому защита CSRF не смогла связать токен с правильный сеанс.

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

у меня была та же ошибка, но в моем случае проблема заключалась в том, что мое приложение использовало несколько доменов первого уровня, в то время как cookie использовал один. Удаление cookie_domain: «.%domain%» с framework.session на config.yml вызвал cookies по умолчанию для любого домена, в котором была форма, и это исправило проблему.

это кажется проблемой при использовании bootstrap, если вы не визуализируете форму с помощью >. Кроме того, проблемы, похоже, возникают только при вводе type=»hidden». Если вы проверите страницу с формой, вы обнаружите, что скрытый ввод не является частью разметки вообще или он визуализируется, но не передается по какой-либо причине. Как было предложено выше, добавление > или упаковка ввода, как показано ниже, должны сделать трюк.

Что означает ошибка «CSRF токен истек»

Если вы столкнулись с ошибкой «истек CSRF-токен» — читайте нашу статью. Из неё вы узнаете, как работает CSRF-token защита, и что делать, если CSRF токен истек.

Ошибка токен истек 1

Что такое CSRF

CSRF (англ. cross-site request forgery) — это межсайтовая подделка запроса. Это атака, которой может подвергаться любой веб-ресурс или веб-приложение. В первую очередь это касается сайтов, которые используют cookies, сертификаты авторизации и браузерную аутентификацию. В результате атаки страдают клиенты и репутация ресурса.

Вредоносный скрипт прячется в коде сайта или обычной ссылке. С помощью него мошенник получает доступ к конфиденциальной информации: платежным реквизитам, логину и паролю, личной переписке. После того как данные “в кармане”, хакер может изменить пароль, указать свой номер телефона или email, перевести деньги на свой счёт и многое другое.

Как работает CSRF-атака

Злоумышленник может использовать фишинговую ссылку — это наиболее распространенный способ обмана. В этом случае атака работает по следующей схеме:

  1. Злоумышленник создаёт поддельную страницу, очень похожую на оригинальную, и встраивает её в сайт. В коде ссылка может выглядеть так: <a href=“вредоносная ссылка”>Unsubscribe here</a>.
  2. Пользователь переходит с одной страницы сайта на другую (например, на страницу оплаты) и вместо реальной страницы попадает на поддельную.
  3. Пользователь совершает действие на странице, например, оплачивает товар или вводит данные авторизации.
  4. Информация или денежные средства вместо оригинального сервера уходят на сервер мошенника.

CSRF-атаки случаются из-за того, что без специальных настроек сервер не может с точностью в 100% определить, кто именно выполняет действия со стороны пользователя. Он не может проверить, действительно ли на кнопку “оплатить” нажал тот пользователь, который изначально открыл страницу с оплатой. Хакеры активно используют этот люфт в безопасности HTTP-запросов и применяют вредоносные скрипты. Однако от атаки можно защититься с помощью CSRF-токенов.

Что такое CSRF-token и как он работает

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

CSRF-token — это максимально простой и результативный способ защиты сайта от CSRF-мошенников. Он работает так: сервер создаёт случайный ключ (он же токен) и отправляет его браузеру клиента. Когда браузер запрашивает у сервера информацию, сервер, прежде чем дать ответ, требует показать ключ и проверяет его достоверность. Если токен совпадает, сессия продолжается, а если нет — прерывается. Токен действителен только одну сессию — с новой сессией он обновляется.

Чтобы получить ответ от сервера, используются разные методы запроса. Условно они делятся на две категории: те, которые не изменяют состояние сервера (GET, TRACE, HEAD), и те, которые изменяют (PUT, PATCH, POST и DELETE). Последние имеют большую CSRF-уязвимость и поэтому должны быть защищены в первую очередь.

При создании и использовании токена должны соблюдаться следующие условия:

нахождение в скрытом параметре;

генерация с помощью генератора псевдослучайных чисел;

ограниченное время жизни (одна сессия);

уникальность для каждой транзакции;

устойчивый к подбору размер (в битах);

Типы токенов

Существует три основных типа токенов по способу генерации:

  1. Synchronizer Tokens или Anti-CSRF (токены синхронизации). В этом случае инициатором ключа выступает сервер — на нём хранится исходная шифровка. Когда браузер обращается к серверу и предъявляет ему ключ, сервер сравнивает его с исходником и в зависимости от результата продолжает или прерывает сессию.
  2. Double Submit Cookie (двойная отправка куки). При этом способе токен нигде не хранится. Когда браузер обращается к серверу впервые за сессию, сервер генерирует и передаёт ему ключ в двух формах: через куки и в одном из параметров ответа. При следующих обращениях браузера сервер дважды проверяет правильность ключа — в параметрах и в куках.
  3. Encrypted Token (зашифрованный токен). Этот способ предполагает, что ключом шифруется какая-то часть информации о клиенте, которая содержится в браузере. При первом запросе браузера сервер получает информацию о пользователе, зашифровывает её и передаёт браузеру токен. При следующем взаимодействии сервер расшифровывает токен и сверяет информацию.

Помимо токенов, для защиты используется флаг Same-Site (большинство браузеров его поддерживает). Он работает напрямую для cookies и позволяет помечать куки конкретного домена. Сервер проверяет, содержатся ли нужные пометки в куках страницы, с которых происходит оплата или вносятся изменения. Если пометок нет — сессия прекращается.

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

«Истек срок действия токена» или «CSRF-значение недопустимо»: что это значит и что делать

Даже при авторизации на сайтах, для которых настроена защита от атак, можно встретить следующие варианты сообщения об ошибке: «Недопустимое CSRF-значение»/«CSRF-токены не совпадают» или «Token expired» (в переводе — срок действия токена истек). Сообщение может отображаться как на английском, так и на русском. Пример ошибки при авторизации на сайте REG.RU:

Ошибка токен истек 2

Обычно ошибка возникает по двум основным причинам:

сервер некорректно сгенерировал токен;

срок токена истек — пользователь долго не совершал никаких действий на странице.

В обоих случаях исправить проблему поможет перезагрузка страницы — вы запустите новую сессию, а значит, сервер и браузер договорятся о новом рабочем токене. Для этого нажмите на значок обновления страницы:

Ошибка токен истек 3

Иногда ошибка возникает из-за расширений защиты конфиденциальности или плагинов блокировки рекламы (например, Ghostery, UBlock Origin, Blur), которые настроены у пользователя. В этом случае можно отключить расширение. Также можно добавить сайт, на котором появилось сообщение, в список доверенных сайтов.

На примере сайта reg.ru покажем, что для этого нужно:

  1. Откройте настройки Chrome: Ошибка токен истек 4
  2. В списке слева выберите Конфиденциальность и безопасность, а затем Файлы cookie и другие данные сайтов.
  3. Внизу страницы откройте Сайты, которые всегда могут использовать файлы cookie и кликните Добавить.
  4. Введите «[*.]www.reg.ru» и нажмите Добавить.
  5. Нажмите Все файлы cookie и данные сайта и удалите все записи, которые связаны с сайтом reg.ru.
  6. Перезагрузите браузер и выполните операцию повторно.
  1. Откройте настройки браузера Яндекс: 20220125_chto_oznachayet_oshibka_csrf_token_istek_5.png
  2. Перейдите на СайтыРасширенные.
  3. Кликните Настройки… для первого параметра в списке. Затем на вкладке «Разрешена» введите www.reg.ruи кликните Добавить.
  4. Добавьте адрес сайта для всех параметров списка по аналогии.
  1. Откройте настройки Safari комбинацией Cmd + , (⌘,).
  2. Перейдите на вкладку Конфиденциальность и проверьте, что в пункте «Файлы cookie и данные веб-сайтов» не выбрано «Блокировать все файлы cookie». Если это так, снимите настройки.
  3. Кликните Управление данными веб-сайтов и удалите все записи, которые относятся к www.reg.ru.
  4. Перезагрузите браузер и выполните операцию повторно.

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

Заключение

Успешная атака CSRF позволяет хакеру действовать на сайте от имени другого зарегистрированного посетителя. Чтобы мошенник не добрался до конфиденциальных данных, для сайта нужно настроить один из типов CSRF-токенов. Токены позволяют серверу и браузеру безопасно обмениваться информацией в течение сессии. Однако даже на безопасных сайтах можно столкнуться с ошибкой «токен CSRF истек». В этом нет ничего страшного. Чтобы возобновить подключение, достаточно обновить страницу браузера.

Понравилась статья? Поделить с друзьями:

Читайте также:

  • Ошибка invalid captcha
  • Ошибка interrupt exception not handled
  • Ошибка internet explorer zonemapping ошибка
  • Ошибка internet download manager
  • Ошибка internal server error вконтакте

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии