Ошибка маркера проверки запроса на вход

Я просматривал журналы ошибок проекта разработки и обнаружил следующую ошибку (имя изменено для защиты виновным невинных)-




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




это не было особенно трудно воспроизвести -




  1. Откройте приложение на странице входа

  2. откройте второе окно или вкладку браузер на тот же компьютер на страницу входа перед входом в систему

  3. войдите в первое окно (или действительно во второе, порядок не имеет значения)

  4. попытка войти в оставшееся окно входа


трассировка стека-




637   4  

4 ответов:

Я только что проверил этот шаблон на ASafaWeb С тем же результатом (он использует ту же реализацию по умолчанию). Вот что я считаю, что происходит

  1. обе формы входа загружаются с одним и тем же файлом cookie __RequestVerificationToken (это один и тот же набор в одном и том же DOM) и одним и тем же скрытым полем _ _ RequestVerificationToken. Эти маркеры предназначены для анонимного пользователя.
  2. войти в форму сообщения с вышеуказанными маркерами, проверяет их, а затем возвращает auth cookie, который теперь находится в браузере DOM
  3. форма входа B должности и с вышеуказанными маркерами, но теперь он также публикует с набором файлов cookie auth из формы входа A.

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

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

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

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

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

честно говоря, я не уверен, что вижу проблему; воспроизвести эта проблема пользователь должен иметь несколько форм входа открыты в то же время, а затем попытаться войти в каждый подряд - это действительно произойдет достаточно, чтобы беспокоиться? И когда это произойдет, действительно ли имеет значение, что второй вход возвращает пользовательскую страницу ошибки (что, конечно, вы бы сделали в производстве)? ИМХО, оставьте поведение по умолчанию.

59  
2013-10-01 10:29:15

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

System.Web.Mvc.HttpAntiForgeryException (0x80004005):
The provided anti-forgery token was meant for user "", but the current user is "SomeOne".

вы можете отключить это, поставив AntiForgeryConfig.SuppressIdentityHeuristicChecks = true; на событий Application_Start способ внутри глобальные.эйсакс файл.

когда AntiForgeryToken не проверяет ваш сайт будет выдавать исключение типа

12  
2015-09-17 10:31:17

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

когда это исключение выбрасывается, вы бы предпочли, чтобы пользователь продолжал, а также, возможно, отображая соответствующее сообщение/предупреждение? Потому что когда это исключение выбрасывается, мы уже можем знать, аутентифицирован ли текущий пользователь-у нас есть доступ к запросу.

Итак, почему бы это не быть приемлемым?

[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public ActionResult Login(LoginModel model, string returnUrl)
{
...
}

/// <summary>
/// Handle HttpAntiForgeryException and redirect if user is already authenticated
/// </summary>
/// <param name="filterContext"></param>
/// <remarks>
/// See: http://stackoverflow.com/questions/19096723/login-request-validation-token-issue
/// </remarks>
protected override void OnException(ExceptionContext filterContext)
{
    base.OnException(filterContext);

    var action = filterContext.RequestContext.RouteData.Values["action"] as string;
    var controller = filterContext.RequestContext.RouteData.Values["controller"] as string;

    if ((filterContext.Exception is HttpAntiForgeryException) &&
        action == "Login" &&
        controller == "MyController" &&
        filterContext.RequestContext.HttpContext.User != null &&
        filterContext.RequestContext.HttpContext.User.Identity.IsAuthenticated)
    {
        LogManager.GetCurrentClassLogger().Warn(
            "Handled AntiForgery exception because user is already Authenticated: " +
                filterContext.Exception.Message, filterContext.Exception);

        filterContext.ExceptionHandled = true;

        // redirect/show error/whatever?
        filterContext.Result = new RedirectResult("/warning");
    }
}

я упускаю что-то очевидное здесь? Я удалю этот ответ, если он есть какой-то подтекст я не вижу.

9  
2015-06-02 18:48:39

У меня была такая же проблема, я решил ее, добавив machineKey система.веб ->

<machineKey validationKey="your machine key numbers" 
decryptionKey="Your description key nuumbers" validation="SHA1" decryption="AES" />

вот сайт, который генерирует уникальные ключи Machnie http://www.developerfusion.com/tools/generatemachinekey/

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

-4  
2014-02-15 09:27:49

Comments

    Ничего не найдено.
Click here to cancel reply.