Проблема с токеном подделки: не при входе в систему или выходе из системы, а при возврате на веб-сайт от обработчика платежей - PullRequest
0 голосов
/ 25 октября 2018

У меня возникла самая странная проблема, которую я не могу правильно отладить.

Текущий проект:

  • Asp.NET 4.7.2
  • MVC 5

Когда пользователь входит в систему, он может выйти из системы и войти обратно без каких-либо проблем.Никаких проблем с токенами нет.Тайм-аут на 60 минут.

Однако на этом сайте есть «корзина», в которую пользователи могут положить очень ограниченные вещи и оплатить их.Кнопка оплаты перемещает их в обработчик платежей (размещенную на странице оплаты страницу), который затем получает информацию CC и обрабатывает этот платеж.После завершения платежа (или его сбоя) пользователь возвращается на определенную страницу веб-сайта, а также в свою учетную запись.Единственное, что делает эта целевая страница, это ищет несколько значений GET, которые обработчик платежей добавил в конец URL, и записывает эти значения в базу данных (тем самым записывая товар в корзину как оплаченный).

Однако около трети людей, получивших ответ от обработчика платежей - после a успешного платежа, -

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

сообщение об ошибке.

Чтобы быть понятным:

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

Мой код включенэта целевая страница чрезвычайно проста:

[HttpGet]
public async Task<ActionResult> Processed() {
  var responseCode = Request.QueryString["RESPONSECODE"];
  var orderId = Request.QueryString["ORDERID"];
  var customField = HelperExtensions.GetGuid(Request.QueryString["CUSTOMFIELD1"]);
  var amount = Convert.ToDecimal(Request.QueryString["AMOUNT"]);
  var cardNumber = Request.QueryString["CARDNUMBER"];
  var approvalCode = Request.QueryString["APPROVALCODE"];
  var uniqueRef = Request.QueryString["UNIQUEREF"];
  var dateTime = Convert.ToDateTime(Request.QueryString["DATETIME"]);
  if(string.Equals(responseCode, "A")) { // Transaction approved
    //Process these values and insert them into the DB to mark the cart as having been paid.
  }
  //Send *everyone* to the View, with appropriate messages served up by the view’s model depending on the responseCode.
  return View("Processed", new ProcessedViewModel(transactionId, responseCode, orderId, amount, cardNumber, approvalCode, uniqueRef, dateTime, additionalErrors));
}

Я уже пытался проверить это с помощью фиктивной учетной записи на сайте и вручную создать обратный URL-адрес, который целевая страница может «обработать», но если я не хочуЧтобы самостоятельно набрать несколько тысяч долларов в виде сборов CC (это членские взносы в диапазоне от нескольких сотен долларов), я не могу работать с полным циклом.

Обратите внимание, что эта проблема явно не появляется во время входа или выхода из системы.Или с логином сразу после выхода. * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* * * * * * * * * * * * * * * * *1050* * * * * * * * * *1051* Также обратите внимание: две трети пользователей не сталкиваются с этой ошибкой.Только около трети из них.Таким образом, это, кажется, временная проблема, и я еще не отследил различия между успешными ловушками на целевой странице и теми ловушками, которые терпят неудачу.

Я зашел так далеко, что украсил все контроллеров с:

[NoCache]
[OutputCache(NoStore = true, Duration = 0, VaryByParam = "*")]

Первым из них является атрибут без кэша, который я нашел в другом месте в StackOverflow:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]
public sealed class NoCacheAttribute : ActionFilterAttribute {
  public override void OnResultExecuting(ResultExecutingContext filterContext) {
    filterContext.HttpContext.Response.Cache.SetExpires(DateTime.UtcNow.AddDays(-1));
    filterContext.HttpContext.Response.Cache.SetValidUntilExpires(false);
    filterContext.HttpContext.Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches);
    filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
    filterContext.HttpContext.Response.Cache.SetNoStore();

    base.OnResultExecuting(filterContext);
  }
}

Несмотря на это добавление, ошибки не исчезли (хотяпока не было достаточно платежей, чтобы определить, изменился ли коэффициент ошибок токенов.

1 Ответ

0 голосов
/ 28 октября 2018

Токены Anti-Forgery работают с cookie-файлами. Если веб-браузер блокирует cookie-файлы, это приведет к ОШИБКЕ.

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

Создайте действие, которое будет регистрировать заблокированные файлы cookieдля сравнения с пользователями с этой проблемой.

Для предотвращения CSRF предусмотрены токены защиты от подделки, при условии, что у вас есть клиент, покидающий сайт для оплаты и возвращающийся в учетную запись пользователя без файла cookie.

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

Посмотрите на этот сайт .

Надеюсь, это поможет

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...