Antiforgerytoken и SPA React с веб-приложением. net framework - PullRequest
Новая
       89

Antiforgerytoken и SPA React с веб-приложением. net framework

0 голосов
/ 29 апреля 2020

В течение последних нескольких дней я пытался найти правильное решение / документацию, объясняющую, как. net framework Антивирусство должно быть настроено для приложения SinglePage без какой-либо удачи.

У меня есть. net каркас веб-приложения с React. Спереди - одностраничное приложение, которое связывается с контроллерами в бэкэнде. Контроллерами являются MVC (не API), но для ответов установлено значение JSON.

Когда-то при внедрении Antiforgery я сталкивался с этой документацией https://docs.microsoft.com/en-us/aspnet/web-api/overview/security/preventing-cross-site-request-forgery-csrf-attacks

Внизу этой документации есть пример Anti-CSRF и AJAX и предлагает следующее: 

    <script>
    @functions{
        public string TokenHeaderValue()
        {
            string cookieToken, formToken;
            AntiForgery.GetTokens(null, out cookieToken, out formToken);
            return cookieToken + ":" + formToken;                
        }
    }

    $.ajax("api/values", {
        type: "post",
        contentType: "application/json",
        data: {  }, // JSON data goes here
        dataType: "json",
        headers: {
            'RequestVerificationToken': '@TokenHeaderValue()'
        }
    });
   </script>

и проверка: 


 void ValidateRequestHeader(HttpRequestMessage request)
   {
    string cookieToken = "";
    string formToken = "";

    IEnumerable<string> tokenHeaders;
    if (request.Headers.TryGetValues("RequestVerificationToken", out tokenHeaders))
    {
        string[] tokens = tokenHeaders.First().Split(':');
        if (tokens.Length == 2)
        {
            cookieToken = tokens[0].Trim();
            formToken = tokens[1].Trim();
        }
    }
    AntiForgery.Validate(cookieToken, formToken);
}

Обратите внимание, что при использовании AntiForgery.GetTokens () дополнительные файлы cookie для клиента не добавляются. Этот метод генерирует необработанные токены (формируйте и готовьте ie - токен). И после проверки он проверяет только необработанные токены, которые отправляются через HTTP-заголовок (в данном случае RequestVerificationToken )

Для моего приложения, поскольку я не использую Razor, я создал контроллер, который генерирует токен анти-подделки, описанный в приведенном выше примере. Как только пользователь вошел в систему, к этому контроллеру делается запрос на получение токена, который используется для всех небезопасных HTTP-запросов от клиента. Проверка идентична примеру, здесь я создал AuthorizeFilter, который проверяет HTTP-заголовок и проверяет токен.

Кажется, все работает нормально. Как только пользователь вошел в систему, создается антиподделка, и после проверки имя пользователя дешифруется из аутентификации-cook ie и сопоставляется с тем, которое зашифровано в токене против подделки.

Что я заметил, так это то, что этот токен подделки, даже если он предназначен только для пользователя, поскольку он содержит зашифрованное имя пользователя, никогда не истекает. Это означает, что я могу войти как пользователь A, получить значение токена antiforgery-token и выйти из системы. Позже, когда снова войдете в систему как пользователь A, я все еще смогу использовать старый токен antiforgery, так как он все еще проверяется очень хорошо.

Может быть, я обдумываю это, но разве CSRF-атака все еще будет возможна, если злоумышленник каким-то образом завладеет этим несостоявшимся токеном противодействия фальсификации и настроит атаку специально для пользователя A?

Опять же, вполне возможно, я представляю себе сложный сценарий, который заставляет меня задаться вопросом, является ли эта реализация вообще правильной.

...