Случайный Токен файла cookie для защиты от подделки и токен поля формы не совпадают в Azure.

Мы получаем случайные ошибки «Токен файла cookie для защиты от подделки и токен поля формы не совпадают», отображаемые в журнале ошибок на нашем сайте, размещенном в Azure. Поняв, что нам нужен статический машинный ключ, мы добавили его в web.config с атрибутами validationKey и decryptionKey, однако у нас по-прежнему появляется случайная ошибка.

Просто чтобы определить мое использование «случайного» здесь, из каждых ~ 200-300 представлений форм это происходит один или два раза. Просто кажется, что произошло слишком много, и это настоящая помеха для наших клиентов, которые доверяют нашим услугам.

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

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

Заранее спасибо.

[ОБНОВЛЕНИЕ] Я только что услышал от пользователя, что я видел это всплывающее окно с ошибкой. Оказывается, они загрузили страницу и ушли на некоторое время, вызвав ошибку. Это отличная новость, поскольку это означает, что проверка просто выполняет свою работу, и ничего сумасшедшего не происходит... Мне просто нужно проверить, указывает ли эта точка данных на остальных пользователей. Учитывая это, как вы все справляетесь с ситуациями, когда срок действия токена истекает? Вы уведомляете пользователя каким-то чистым способом?


azure asp.net-mvc antiforgerytoken
person lostdeveloper    schedule 26.10.2016    source источник
comment
Пытается ли кто-то отправить данные вредоносной формы, т. е. выполняет ли токен свою работу?   -  person Liam    schedule 26.10.2016
comment
Действительно, кто знает. Без рекреационных ступеней причин может быть много.   -  person Liam    schedule 26.10.2016
comment
Это настоящие пользователи, которые на законных основаниях пытаются использовать наши сервисы, поэтому я не вижу причин, по которым они отправляют вредоносные данные формы. Существует также другая форма вредоносных данных, например использование тегов Html или script, но она генерирует другой тип ошибки.   -  person lostdeveloper    schedule 26.10.2016
comment
Что касается шагов воспроизведения, это самая сложная часть всего этого, поскольку мы не можем воспроизвести это сами. Это просто странный сценарий вокруг.   -  person lostdeveloper    schedule 26.10.2016
comment
Возможно, это поможет: stackoverflow.com/questions/5767768/   -  person Peter B    schedule 26.10.2016
comment
@PeterB, спасибо за ссылку. То, что я вижу по этой ссылке, действительно зависит от файлов cookie, поэтому мы можем добавить проверку для этого. Первоначальный вопрос по этой ссылке касается постоянной проблемы с токеном защиты от подделки, тогда как у нас очень прерывистая.   -  person lostdeveloper    schedule 26.10.2016
comment
Выяснилось, что это была ложная тревога. Я предполагаю, что мы получаем столько пользователей, у которых истек срок действия токенов. Теперь нам просто нужно найти хороший способ показать им ошибку.   -  person lostdeveloper    schedule 31.10.2016

Ответы (2)


arrow_upward
0
arrow_downward

У вас есть ферма серверов? у вас есть служба приложений с включенным автоматическим масштабированием? или облачный сервис с несколькими машинами?

Если да, убедитесь, что все ваши машинные ключи определены с одним и тем же значением во всех ваших файлах web.config. Ключ машины используется для создания токенов AntiForgery.

person Toine Seiter    schedule 26.10.2016
comment
Я предполагаю, что, поскольку мы находимся в Azure, мы автоматически находимся в своего рода ферме серверов. MachineKey определен в единственном развернутом web.config, поэтому я не вижу возможности иметь конфликтующие файлы web.config. - person lostdeveloper; 26.10.2016
comment
в порядке. файл cookie по умолчанию, используемый asp.net для управления токеном AntiForgery, — __RequestVerificationToken. - person Toine Seiter; 26.10.2016
comment
Если у вас есть служба приложений Azure, вы можете перейти на портал.azure.com › Службы приложений › ваше приложение › План службы приложений › Масштабирование, чтобы проверить политику автомасштабирования и узнать, сколько экземпляров у вас есть. - person Toine Seiter; 26.10.2016
comment
Я посмотрел на количество экземпляров. Он настроен на количество экземпляров, которое я ввожу вручную. В настоящее время установлено значение 1. - person lostdeveloper; 26.10.2016
comment
Итак, у вас есть только один сервер с определенным машинным ключом. Вы пытались дважды щелкнуть по отправке страницы, которая выдает ошибку? - person Toine Seiter; 27.10.2016
comment
Хорошее предложение. Я пытался щелкнуть несколько раз, но я все еще не могу сломать его. - person lostdeveloper; 27.10.2016

arrow_upward
0
arrow_downward

Не могли бы вы зарегистрировать заголовки неудачных запросов? Вы можете добавить некоторый код в свой global.asax на Application_Error, например:

foreach (string header in request.Headers)
{
     // header <== header name
     // request.Headers[header]) <== header value
 }
person Toine Seiter    schedule 27.10.2016
comment
Прежде всего, еще раз спасибо за вашу помощь в этом. Очень признателен. Что касается регистрации заголовков, что я должен там искать? Кроме того, я публикую обновление для этого вопроса на основе отзывов, которые я только что получил от пользователя. - person lostdeveloper; 27.10.2016
comment
Вы сможете увидеть, есть ли файл cookie токена защиты от подделки, и, возможно, некоторые другие интересные вещи. POST без этого файла cookie на URL-адресе, который должен иметь его, может быть хитом сканера или хакера. - person Toine Seiter; 27.10.2016
comment
Если все заголовки в порядке, это может быть использование ваших пользователей. Рассмотрим следующие варианты использования: 1) Ваша форма находится на кэшированной странице (кэш на стороне клиента). Генерируется токен защиты от подделки A 2) пользователь проверяет форму 3) затем нажимает кнопку «Назад» в своем браузере 4) пользователь повторно проверяет форму (со старым токеном A) 5) asp.net ожидает анти- подделайте жетон B и получите A. поэтому он выдает исключение. Чтобы избежать этого, клиентский кеш должен быть отключен для URL-адреса с формой, содержащей антифальсификацию. - person Toine Seiter; 27.10.2016