Error csrf token has expired

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

Что такое CSRF

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типы токенов

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Эта статья научит вас, как исправить ошибку «CSRF token истёк», которую вы можете получить при посещении сайта, и больше расскажет о CSRF-атаках в целом.

Что такое CSRF

CSRF (от англ. cross-site request forgery) или межсайтовая подделка запроса – это форма атаки на любой сайт или веб-приложение. С помощью подделки запросов мошенник обманом заставляет пользователя выполнять нежелательные действия на, казалось бы, проверенной платформе.

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

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

Выполнение CSRF-атаки состоит из двух основных частей.

1. Злоумышленник заставляет жертву щёлкнуть на ссылку или загрузить веб-страницу. Он намеренно заманивает пользователя перейти по ссылке, используя методы социальной инженерии.
2. Отправляет «поддельный» или выдуманный запрос в браузер жертвы. Вредоносная ссылка отправит запрос в веб-приложение, однако будет включать в себя значения, которые выгодны злоумышленнику.

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

Примеры CSRF-атаки

Для того, чтобы получить ответ от сервера, в протоколе применяют различные методы HTTP-запросов. Наиболее часто используемые – это GET, POST, PUT, PATCH и DELETE.

Они используются и для создания межсайтовой подделки запроса.

Пример GET CSRF-атаки:

В следующем примере показано, как выглядит типичный GET-запрос для банковского перевода в размере 1000 долларов.

GET https://randombank.ru/transfer.do?account=RandPerson&amount=$1000 HTTP/1.1

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

GET https://randombank.ru/transfer.do?account=SomeAttacker&amount=$1000 HTTP/1.1

Если задействованное приложение ожидает GET-запрос, злоумышленник может разместить на своем веб-сайте тег, который вместо ссылки на изображение отправит поддельный запрос.

<img src=»вредоносная ссылка» />

Пример POST CSRF-атаки:

<h1>Вы выиграли приз!</h1>

<form action=” www.shopshop.ru/api/account» method=”post”>

<input type=”hidden” name=”Transaction” value=”withdraw” />

<input type=”hidden” name=”Amount” value=”1000000″ />

<input type=”submit” value=”Click Me”/>

</form>

1. Пользователь входит на сайт www.shopshop.ru с помощью своих логина и пароля.
2. Сервер авторизует пользователя, а ответ от сервера включает файл cookie аутентификации.
3. Не выходя из системы, пользователь посещает вредоносную веб-страницу. Этот сайт содержит HTML-форму, указанную выше.
4. Пользователь нажимает кнопку отправки. Браузер отправляет файл cookie аутентификации вместе с запросом.
5. Сервер обрабатывает запрос, учитывая, что пользователь уже находится в аккаунте, поэтому злоумышленник получает доступ ко всему, что разрешено делать авторизованному пользователю.

Что такое токен CSRF

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

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

Таким образом, можно выделить основные признаки токена CSRF:

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

Ошибки CSRF: почему возникают и как их исправить?

Сообщения «Неверный токен CSRF» или «Срок действия токена CSRF истёк» означает, что ваш браузер не смог создать безопасный файл cookie или не смог получить доступ к этому файлу cookie для авторизации вашего входа в систему.

Это может быть вызвано плагинами, расширениями, блокирующими рекламу, а также самим браузером, если ему не разрешено устанавливать файлы cookie.

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

• срок действия старого токена действительно истёк, так как прошло более 24 часов;
• уже был отправлен новый токен, в связи с чем старый стал недействительным;
• плагины или расширения блокируют запросы;
• браузеру не разрешено устанавливать файлы cookie.

Иногда нужно лишь обновить свою страницу или вновь войти в систему, и всё будет готово для продолжения вашей работы. Если это не помогает, есть способы исправить это в разных браузерах.

Как исправить ошибки CSRF в браузерах

Google Chrome

1. В правом верхнем углу экрана щёлкните на значок с тремя точками и в меню выберите Настройки.

1. В панели слева откройте вкладку Конфиденциальность и безопасность.
2. Выберите Файлы cookie и другие данные сайтов.

1. Пролистайте до раздела «Специальные настройки» и щёлкните Добавить рядом с графой «Сайты, которые всегда могут использовать файлы cookie».
2. Чтобы включить сайт в этот список, введите название нужного сайта по форме [*.]ваш.сайт и затем нажмите Добавить.

1. В разделе Посмотреть все разрешения и данный сайтов найдите nic.ru и удалите все записи, связанные с сайтом.
2. Перезагрузите браузер и вновь войдите на сайт.

Microsoft Edge

1. Откройте меню в правом верхнем углу экрана и щёлкните Настройки.
2. В параметрах перейдите в раздел Файлы cookie и разрешения сайтов.
3. Нажмите «Управляйте файлами cookie и данными сайта…».

1. Нажмите Добавить рядом со словом «Разрешить», чтобы внести сайт в список и позволить браузеру сохранять с него файлы cookie.
2. Введите [*.]ваш.сайт и подтвердите своё решение, нажав Добавить.
3. Перейдите во вкладку Посмотреть все файлы cookie и данные сайта и удалите всё, связанное с выбранным сайтом.

1. Перезагрузите браузер.

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

1. Откройте меню, щёлкнув на значок с тремя линиями в верхнем углу экрана, и перейдите в Настройки.

1. В левой панели выберите вкладку Сайты и найдите в ней опцию Расширенные настройки сайтов.
2. Пролистайте вниз до раздела Cookie-файлы. Откройте Настройки сайтов под ним.
3. Нажмите Добавить.

1. Введите [*.]ваш.сайт и подтвердите своё решение, нажав Добавить.
2. Вернитесь на предыдущую страницу и перейдите в Cookie-файлы и данные сайтов. Кнопка находится рядом с Настройками сайтов.
3. Удалите все данные о сайте.
4. Перезагрузите браузер.

Opera

1. В левой панели экрана щёлкните на значок Настроек.
2. Выберите раздел Безопасность, а затем нажмите Файлы cookie и прочие данные сайтов.

1. В разделе «Настраиваемое поведение» у параметра Сайты, которые всегда могут использовать файлы cookie щёлкните Добавить.

1. Введите [*.]ваш.сайт и подтвердите своё решение, нажав Добавить.
2. Чуть выше выберите опцию Все файлы cookie и данные сайта и удалите все данные о сайте.
3. Перезагрузите ваш браузер и вновь откройте сайт.

Safari

1. Откройте Настройки Safari в верхней части экрана или с помощью сочетания клавиш Cmd + ,.
2. Перейдите на вкладку Конфиденциальность и убедитесь, что для параметра «Файлы cookie и данные веб-сайтов» не установлено значение «Блокировать все файлы cookie».
3. Затем нажмите Управлять данными веб-сайта…, найдите [ваш.сайт] и удалите все записи, связанные с сайтом.
4. Перезагрузите Safari и проверьте сайт на наличие ошибки.

Заключение

Файлы cookie изначально уязвимы перед CSRF-атаками, поскольку они автоматически отправляются с каждым запросом. Это позволяет злоумышленникам легко создавать вредоносные запросы, которые приводят к межсайтовым подделкам запросов. Хотя извлечение конфиденциальной информации не является основной целью атаки CSRF, это может оказать неблагоприятное воздействие на используемое приложение.

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

You should always check if CSRF protection is working. With Flask this is not obvious.

https://unsplash.com/@christineashleydonaldson

I never really checked if CSRF protection was working in my Flask application, this website. Is it enabled by default? From the Flask_WTF extension documentation:

Any view using FlaskForm to process the request is already getting CSRF protection.

And from the text of Miguel Grinberg’s post ‘Cookie Security for Flask Applications’:

If you are handling your web forms with the Flask-WTF extension, you are already protected against CSRF on your forms by default.

It should be enabled, let’s check if this is true. On the page with the form I added:

<script>
$(document).ready(function(){
    $('#csrf_token').val('ABC');
});
</script>

Then I refreshed the form. In the debugger I verified that the csrf_token changed to ‘ABC’.  Clicking the submit button should give a CSRF error, well I expected a CSRF exception. For me, no exception, which means no CSRF protection. How is this possible? Did it have to do with the fact that I am using DispatcherMiddleWare or is something else wrong?

Yes, something was wrong. Me! And it was caused by TL;DR. There was in fact a CSRF error but not a CSRF exception. I have many forms, mostly in the admin section, and they have been working with CSRF protection all the time without any CSRF error. What is going on?

My testapp:

def create_app():
    fname = 'create_app'
    print(fname + '()')

    app = Flask(__name__)

    app.config['SECRET_KEY'] = 'some-secret-key'

    class MyCSRFForm(FlaskForm):
        submit = SubmitField(_l('Send'))

    @app.route('/csrf_form', methods=['GET', 'POST'])
    def csrf_form():
        fname = 'csrf_form'
        print(fname + '()')

        form = MyCSRFForm()
        if form.validate_on_submit():
            print(fname + ': no validate_on_submit errors, processing form')

        print(fname + ': form.errors = '.format(form.errors))
        for field, errors in form.errors.items():
            print(fname + ': form.errors, field = {}, errors = {}'.format(field, errors))
                
        return render_template('csrf_form.html', form=form)

and the csrf_form.html template:

<html>
<head></head>
<body>

<form method="post">
    {{ form.csrf_token }}
    <p>{{ form.submit() }}</p>
</form>

<script>
elem = document.getElementById('csrf_token');
elem.setAttribute('value', 'ABC'); 
</script>

</body>
</html>

The result:

csrf_form: form.errors, field = csrf_token, errors = ['The CSRF token is invalid.']

There is more information about this in ‘Inconsistency with raising CSRFError #381’, see the links below. It appears that you can use Flask-WTF CSRF protection in two ways:

• as a CSRF error message during form validation
• as a CSRF exception

Both have advantage and disadvantages. I decided to go for the CSRF exception because there is no way you can forget this by accident. To generate CSRF exceptions, I added the suggested code in my __init__.py:

from flask_wtf.csrf import CSRFProtect
csrf = CSRFProtect()
...

def create_app(project_config):
    ...
    # csrf protection
    csrf.init_app(app)

Now when I submit the form I get a CSRF exception:

Bad Request
The CSRF token is invalid.

I changed the jQuery and removed the field name csrf_token:

<script>
$(document).ready(function(){
    $('#csrf_token').attr({name: 'nothing'});
});
</script>

Refresh and submit, the CSRF exception is:

Bad Request
The CSRF token is missing.

And as a final test we remove the script and set the CSRF token expire time to 5 seconds in create_app():

    app.config['WTF_CSRF_TIME_LIMIT'] = 5

The CSRF exception is:

Bad Request
The CSRF token has expired.

Summary of these tests:

• The http error code is 400 Bad Request
• It appeared CSRF protection was working by default and can be implemented in two ways, the documentation is not very clear on this
• I wanted CSRF exceptions and added the suggested extra code
• It was very easy to generate CSRF exceptions for the conditions:
  — The CSRF token is invalid
  — The CSRF token is missing
  — The CSRF token has expired

Multiple forms and the CSRF token

A blog post page on this site has two types of comment forms: the comment form and the comment reply form, see also a previous post.
When looking at the page with the comment form and comment reply form I noticed that both had the CSRF token value after a page load.

comment form: 
<input id="comment_form-csrf_token" name="comment_form-csrf_token" type="hidden" value="IjM4N2Y3NmEzMGFkNGMwOTY2MzM5OGI0NTVjOGQwNDI3MjY3MmQxOGIi.Xk6ReA.dFbMlM0bClY6BvAVjxZ0GfiFBM4">

comment reply form: 
<input id="comment_reply_form-csrf_token" name="comment_reply_form-csrf_token" type="hidden" value="IjM4N2Y3NmEzMGFkNGMwOTY2MzM5OGI0NTVjOGQwNDI3MjY3MmQxOGIi.Xk6ReA.dFbMlM0bClY6BvAVjxZ0GfiFBM4">

or:

comment_form-csrf_token: IjM4N2Y3NmEzMGFkNGMwOTY2MzM5OGI0NTVjOGQwNDI3MjY3MmQxOGIi.Xk6ReA.dFbMlM0bClY6BvAVjxZ0GfiFBM4

comment_reply_form-csrf_token: IjM4N2Y3NmEzMGFkNGMwOTY2MzM5OGI0NTVjOGQwNDI3MjY3MmQxOGIi.Xk6ReA.dFbMlM0bClY6BvAVjxZ0GfiFBM4

Then I submit a too short message using the comment reply form. The form is send to the server, rendered at the server and send back to the client.
Inspection showed that the CSRF token of the comment reply form changed:

comment_reply_form-csrf_token: IjM4N2Y3NmEzMGFkNGMwOTY2MzM5OGI0NTVjOGQwNDI3MjY3MmQxOGIi.Xk6SUg.6axMGCN2KmQQ4WeAAxYgTg6UdAs

Here the following questions came up:

• How is the CSRF token constructed?
• When does the CSRF token expire?
• Do different forms on a page require different CSRF token?
• How can the CSRF token of the comment reply form change?
• What is the X-CSRFToken?

How is the CSRF token constructed?

Time to start reading again. From the OWASP guide:

In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is used for each subsequent request until the session expires.

In Flask-WTF the raw token is in the session and the signed token is in g. Or more accurate, the raw token is always in the session and the signed token is in g after a form has been used. Before instantiating a form:

session['csrf_token']: 387f76a30ad4c09663398b455c8d04272672d18b
g.csrf_token: None

After instantiating a form:

session['csrf_token']: 387f76a30ad4c09663398b455c8d04272672d18b
g.csrf_token: IjM4N2Y3NmEzMGFkNGMwOTY2MzM5OGI0NTVjOGQwNDI3MjY3MmQxOGIi.Xk6vnw.L7uNOptXpBxemh_TIEy3e9Ujllg

The signed token is put in g so that with subsequent requests, for example in case of multiple forms, the same signed token can be used and does not have to be generated again. If you want you can experiment with generating and validating tokens using the functions generate_csrf() and validate_csrf():

    from flask_wtf.csrf import generate_csrf, validate_csrf

    secret_key = current_app.config['SECRET_KEY']
    # default: WTF_CSRF_FIELD_NAME = 'csrf_token'
    token_key = current_app.config['WTF_CSRF_FIELD_NAME']

    csrf_token = generate_csrf(secret_key=secret_key, token_key=token_key)
    current_app.logger.debug(fname + ': csrf_token = {}'.format(csrf_token))

    validated = False
    try:
        validate_csrf(csrf_token, secret_key=secret_key, time_limit=3600, token_key=token_key)
        validated = True
    except:
        pass
    current_app.logger.debug(fname + ': validated = {}'.format(validated))

The above functions do something like a black box. But we can see that the generated token is signed and includes a timestamp.

When does the CSRF token expire?

We already saw that the CSRF token expire time can be controlled with:

    app.config['WTF_CSRF_TIME_LIMIT'] = 5

The default value is 3600, one hour. This time is somewhere in the token. There can be two possible ways how this is implemented:

• The start time is in the CSRF token
• The end time is in the CSRF token

This is not important to know unless you want to change the expire time inside your application. The generate_csrf() function does not include a time_limit parameter while the validate_csrf does. This would mean that the start time is in the CSRF token. To verify this I put a page with a form on the screen, then changed the default time_limit to 10 seconds and then submitted the form. As expected, a CSRF exception was raised.

There is another condition when your CSRF token expires and that is when the session expires. The reason is that the CSRF raw token is stored in the session. This means that if your session lives shorter than your CSRF token expire time you can get CSRF errors.

Do different forms on a page require different CSRF token?

Answer: This is more a general question. The answer is no. We can use the same CSRF token for all forms on a page.

How can the CSRF token of the comment reply form change?

Answer: The token does not change but the signed token changes, because there also is a timestamp in the signed token. If you look at the signed tokens above you notice that the first part is identical.

The X-CSRFToken header parameter

You may have read about the X-CSRFToken. The X-CSRFToken is a setting in the header. Usually we do not need this. If you have a CSRF token parameter in your AJAX POST then this will be used. If not then can set this in the header of the POST using jQuery:

var csrf_token = ...

    ...
    $.ajax({
        beforeSend: function(xhr, settings){
            if(!/^(GET|HEAD|OPTIONS|TRACE)$/i.test(settings.type) && !this.crossDomain){
                xhr.setRequestHeader("X-CSRFToken", csrf_token);
            }
        },

It depends on your implementation if you send forms with a CSRF token parameter or if you set the X-CSRFToken header parameter. The documentation states you can only use this in ‘CSRF exception mode’ (adding the extra code). I did not check this.

Handling CSRF exceptions and before_request

I already handle HTTP error exceptions like 401 (Unauthorized), 403 (Forbidden), 404 (Not Found), 405 (Method Not Allowed), 500 (Internal Server Error) but how do we handle the CSRF exception? The CSRF error propagates to a 400 (Bad Request).

I created nice bells and whistles error pages showing the exceptions. I did this by relying on the fact that that before_request was called.
In before_request I process the incoming request and among other things, set the selected language accordingly.

Unfortunately by default before_request is NOT called on a CSRF exception. But there is a way around this. We can set:

    app.config['WTF_CSRF_CHECK_DEFAULT'] = False

The result will be that before_request is called. Then in before_request, after some essential processing, we can call:

    csrf.protect()

This will raise a CSFR exception, if there is one, and call the error handler accordingly.

Multi-language CSRF exception messages

I use Flask-Babel and validation messages are translated into the selected language. The CSRF exception messages did not translate and checking csrf.py it appeared that these messages are hard-coded in English(?). For the moment I created a dictionary to handle the translation:

    csrf_error_message2translated_error_messages = {
        ...
        'The CSRF token has expired.': _('The CSRF token has expired.'),
        ...
    }
    if error.description in error_description2error_messages:
        error_message = error_description2error_messages[error.description]
    else:
        error_message = error.description

Responding to exceptions, including CSRF, on AJAX requests

With AJAX we cannot show our nice HTML error page on an exception. On a request we must return an error code or HTML that the client understands. It comes down to returning the exception as a JSON encoded error message to the client. In Flask we already have our error handlers.
But how do we know that the request was coming from an AJAX call? I am sending the form with encoding application/x-www-form-urlencoded:

    $.ajax({
        data: $('#' + form_id).serialize() + '&' + encodeURI( $(submit_button).attr('name') ) + '=' + encodeURI( $(submit_button).val() ),
        type: 'POST',
        url: url_comment_new,
        contentType: 'application/x-www-form-urlencoded; charset=UTF-8', 
        dataType: 'json'
    })

One way is to look at the received Accept header.

    current_app.logger.error(fname + ': request.accept_mimetypes = {}'.format(request.accept_mimetypes))
    # text/javascript,application/json,*/*;q=0.01

From the document ‘List of default Accept values’:

Note that all browsers add the */* MIME Type to cover all cases. This is typically used for requests initiated via the address bar of a browser, or via an HTML <a> element.

This means that both ‘request.accept_mimetypes.accept_json’ and ‘request.accept_mimetypes.accept_html’ are True. Not very useful. The accept_mimetypes are listed in order of preference. We could scan the list and decide to return JSON when encountering ‘application/json’ before ‘text/html’. But I do not know exactly which browsers send which accept_mimetypes, meaning that I am not 100% sure at this moment that the ‘without AJAX’ error pages will not accidently be shown as JSON.

A much safer way is to add a parameter to AJAX requests and check in the error handler if this parameter is present. If it is present then we return a JSON error message, if it is not we output the standard error page. I do not like this but it works and some time will dig deeper into this.

Summary

You should always check if CSRF protection is working. I did not, and that was the start of very much reading. It appeared that are two ways to deal with CSRF protection, CSRF form error and CSRF exception. I choose the second one. For me, handling CSRF protection for this multilanguage site was not standard, the main reason being that before_request is not called by default on a CSRF exception. In before_request I check and set the language among other things so this really must run. Fortunately we can delay the CSRF protection and call it explicitly in before_request after essential processing using csrf.protect(). We already have our exception error pages but with AJAX requests we must return JSON error messages. Detecting if the request comes from an AJAX request is complex so I used an extra parameter in the AJAX requests.

Задача:

Найти причину возникновения ошибки “Missing or expired CSRF token” и варианты решения

—————————————————————

CSRF (Cross-Site Request Forgery) – это «межсайтовая подделка запроса» или ещё называют “подделка HTTP-запросов”, также известна как XSRF. Суть атаки заключается в том, что браузер пользователя отправляет сайту значение Cookie, т.е. запрос будет воспринят как исходящий от аутентифицированного пользователя.

В нашем случае надо знать версию pfSense. До версии 2.4.2, веб-интерфейс был уязвим для Clickjacking. Уязвимость имела название “CVE-2017-1000479” и позволяла злоумышленнику выполнить произвольный код с привилегиями root. Поэтому обновляемся.

Если у вас версия pfSense 2.4.2 и выше, то скорее всего вы были авторизованны в веб-интерфейсе администрирования и после работы не вышли.

Missing or expired CSRF token

Form session may have expired, cockies may not be enabled, or possible CSRF-based attack.

Resubmitting this request may put the firewall at risk or lead to unintended behavior.

I undestand this warning and wish to resubmit the form data.

Resubmit Request with New Token

Поэтому не забываем выходит “logout”. Сделать это можно через иконку в виде стрелочки вправо и расположенной в правой, верхней части окна веб-интерфейса.

Решений данной проблемы, у меня было два:

• Удалить кеш браузера и попробовать перезайти или воспользоваться другим браузером
• Поставить галочку напротив “I undestand this warning and wish to resubmit the form data.” и нажать “Resubmit Request with New Token”

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

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

• платежные реквизиты;

• личные  сообщения;

• доступы к разным аккаунтам;

• и др.

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

Что такое CSRF-атака?

CSRF — это «cross-site request forgery» и переводится как «межсайтовая подделка запросов». Этот вид атаки строится на «пробелах в безопасности» HTTP-запросов. Например, пользователь ничего не подозревает и заходит на какой-то сайт, который создал злоумышленник. Пока пользователь находится на зловредном сайте, злоумышленник отправляет от его лица запросы на сервера других веб-ресурсов. Например, хакер может от лица этого пользователя перевести деньги на собственный счет с пользовательского онлайн-банка. Самое главное, чтобы в этот момент пользователь был аутентифицирован на атакуемом ресурсе и там не требовалось подтверждение проводимых операций. К примеру, пользователь осуществлял оплату в интернет-банке, страница интернет-банка осталась открытой, а пользователь перешел на сайт злоумышленника. 

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

То есть  CSRF — это  способ провести операцию на уязвимом сайте от имени атакуемого пользователя. С помощью CSRF хакер может:

• изменить пароль;

• восстановить пароль;

• поменять номер телефона на собственный;

• поменять электронную почту на собственную;

• добавить пользователя  в аккаунт;

• что-либо оплатить;

• и др.

CSRF-атаки доступны по простой причине. Браузер во время сессии не способен точно определить кто выполняет  некоторые действия: пользователь или программа. Например:

• кто нажал на кнопку;

• кто перешел по ссылке;

• кто написал;

•  и др.

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

CSRF-token — что это?

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

CSRF-token обычно защищает только небезопасные HTTP-запросы, например:

• POST;

• PUT;

• DELETE;

• PATCH.

Безопасные методы HTTP-запросов нет смысла дополнительно защищать токеном.

К CSRF-token применяются следующие требования:

• должен быть уникальным для каждой отдельной операции;

• должен действовать единоразово;

• обладает  размером, который обеспечивает ему устойчивость к подбору;

• генерируется специальным криптографическим генератором случайных чисел;

• имеет ограничение по времени жизни.

Виды CSRF-токенов

CSRF-token может генерироваться и использоваться тремя способами:

1. Synchronizer Tokens. Это самый простой и распространенный  способ использования CSRF-токена. В этом случае токен генерируется сервером и передается браузеру, при этом «копия» токена сохраняется на сервере. Потом происходит сверка токена браузера и токена, который сохранен на сервере. Когда сессия между браузером и сервером обновляется, тогда обновляется и CSRF-token.

2. Double Submit Cookie. В таком методе токен не хранится на сервере, а передается браузеру в двух экземплярах: в куках и в каком-то параметре ответа. При первом запросе к серверу, сервер формирует токен. Потом сервер передает его обратно браузеру, но в двух местах:  в куках и еще в каком-то месте. При следующем обращении к серверу, у браузера проверяется наличие и идентичность токенов в обоих местах.

3. Encrypted Token. В этом случае в качестве токена является конкретная информация о клиенте, но зашифрованная специальным ключом. То есть при первом обращении к серверу из какой-то информации о браузере генерируется токен и помещается в какой-то параметр ответа. При последующих обращениях браузер должен вернуть токен. Токен расшифровывается и информация из токена должна совпасть с информацией о браузере.

Заключение

CSRF-token — это рабочий способ защититься от CSRF-атак. Даже самый простой способ генерации CSRF-токена обеспечивает надежную защиту. А защитой, как известно, не нужно пренебрегать.

I can confirm that I am encountering this issue too. However I am not able to build a snippet for reproducing the bug every time.

If I am filling a faulty form in a private tab, the issue does not appear. Can you confirm that?

What wtforms version are you using?

edit: My website answers to two domains, strangely one is encountering this issue, and the other is not. On the failing domain, there are two session cookies, one which domain is .domain1.tld and another one which domain is domain1.tld, without the starting dot. On the succeeding domain, there is only one session cookie, which domain is domain2.tld, without the starting dot.

edit2: In the failing domain, I can see that every form submission passes through this line. It feels like session['csrf_token'] is never written, or deleted somewhere else, or written in th.

https://github.com/lepture/flask-wtf/blob/c0e42ac78c347d0d26496a8903b854f24f1b3107/flask_wtf/csrf.py#L46-L47

edit3: This issue may be related. It seems this issue is encountered when several session cookies are involved.

edit4: The requests set-cookie header content matches the session id of the cookie whose domain is domain1.tld but the response Cookie header matches has both session ids, the first one being the session id of the cookie whose domain is .domain1.tld and the second one being the session id of the cookie whose domain is domain.tld.