Защита ASP.NET Core Blazor WebAssembly

Защита приложений Blazor WebAssembly обеспечивается аналогично защите одностраничных приложений (SPA). Существует несколько подходов к проверке подлинности пользователей в одностраничных приложениях, но наиболее распространенным и комплексным является использование реализации на основе протокола OAuth 2.0, например, OpenID Connect (OIDC).

Документация Blazor WebAssembly по безопасности в основном посвящена выполнению задач проверки подлинности и авторизации пользователей. Общие понятия OAuth 2.0/OIDC см. в разделе "Дополнительные ресурсы" статьи "Дополнительные ресурсы".

Безопасность на стороне клиента или SPA

Blazor WebAssembly База кода .NET/C# приложения обслуживается клиентами, а код приложения не может быть защищен от проверки и изменения пользователями. Никогда не помещайте что-либо из секрета в Blazor WebAssembly приложение, например частный код .NET/C#, ключи безопасности, пароли или другие типы конфиденциальной информации.

Чтобы защитить код .NET/C# и использовать функции ASP.NET Core Data Protection для защиты данных, используйте серверный веб-API ASP.NET Core. Вызовите клиентское приложение веб-API на стороне Blazor WebAssembly сервера для безопасных функций приложений и обработки данных. Дополнительные сведения см. в статье "Вызов веб-API" из приложения ASP.NET Core Blazor и статей в этом узле.

Библиотека проверки подлинности

Blazor WebAssemblyподдерживает проверку подлинности и авторизацию приложений с помощью OIDC через библиотеку Microsoft.AspNetCore.Components.WebAssembly.Authentication с помощью Платформы МайкрософтIdentity. Библиотека предоставляет набор примитивов для простой проверки подлинности на серверных компонентах ASP.NET Core. Библиотеку можно использовать для проверки подлинности любого стороннего поставщика Identity (IP), который поддерживает OIDC (их называют поставщиками OpenID (OP)).

Поддержка проверки подлинности в Blazor WebAssembly библиотеке (Authentication.js) основана на библиотеке проверки подлинности Майкрософт (MSAL, msal.js), которая используется для обработки сведений о базовом протоколе проверки подлинности. Библиотека Blazor WebAssembly поддерживает только поток кода проверки подлинности для кода Exchange (PKCE). Неявное предоставление не поддерживается.

Кроме того, доступны другие варианты проверки подлинности одностраничных приложений, например использование файлов cookie SameSite. Однако проектирование использования OAuth и OIDC в качестве оптимального Blazor WebAssembly варианта проверки подлинности в Blazor WebAssembly приложениях. По соображениям безопасности и в силу функциональных причин, проверка подлинности на основе токенов, на основе JSON Web Tokens (JWTs), была выбрана вместо проверки подлинности на основе файлов cookie.

• Использование протокола на основе токенов позволяет уменьшить контактную зону атак, так как токены отправляются не во всех запросах.
• Конечные точки сервера не нуждаются в защите от подделки межсайтовых запросов (CSRF), так как токены отправляются явным образом. Это позволяет размещать приложения Blazor WebAssembly параллельно с приложениями MVC или Razor Pages.
• Разрешения токенов более узкие, чем разрешения файлов cookie. Например, токены нельзя использовать для управления учетной записью пользователя или изменения пароля пользователя, если такие функции не реализованы явным образом.
• У токенов короткий срок жизни (по умолчанию — один час), что ограничивает распространение атаки. Токены можно отозвать в любое время.
• Автономные токены JWT гарантируют выполнение надлежащего процесса проверки подлинности на клиенте и сервере. Например, на клиенте есть средства для обнаружения и проверки допустимости получаемых токенов, а также подтверждения их выпуска в рамках данного процесса проверки подлинности. Если третья сторона пытается изменить токен в ходе процесса проверки подлинности, клиент может обнаружить измененный токен и не использовать его.
• Токены с OAuth и OIDC обеспечивают безопасность приложения вне зависимости от поведения агента пользователя.
• Протоколы на основе токенов, такие как OAuth и OIDC, позволяют выполнять проверку подлинности и авторизацию пользователей в автономных Blazor приложениях Webassembly с одинаковым набором характеристик безопасности.

Внимание

Для версий ASP.NET Core, которые принимают Duende Server в Blazor шаблонах проектов, Duende Software может потребоваться оплатить плату за использование сервера Duende IdentityIdentity в рабочей среде. Дополнительные сведения см. в статье Миграция с ASP.NET Core 5.0 на 6.0.

Процесс проверки подлинности с использованием OIDC

Библиотека Microsoft.AspNetCore.Components.WebAssembly.Authentication предлагает несколько примитивов для реализации проверки подлинности и авторизации с помощью OIDC. В общих чертах проверка подлинности работает следующим образом.

• Когда анонимный пользователь выбирает кнопку входа или запрашивает Razor компонент или страницу с [Authorize] примененным атрибутом , пользователь перенаправляется на страницу входа приложения (/authentication/login).
• На странице входа библиотека проверки подлинности готовится к перенаправлению на конечную точку авторизации. Конечная точка авторизации находится вне приложения Blazor WebAssembly и может размещаться в отдельном источнике. Конечная точка определяет, прошел ли пользователь проверку подлинности, и выдает в ответ один или несколько токенов. Библиотека проверки подлинности предоставляет обратный вызов входа для получения ответа проверки подлинности.
  • Если пользователь не прошел проверку подлинности, он перенаправляется в базовую систему проверки подлинности. Обычно это ASP.NET Core Identity.
  • Если пользователь уже прошел проверку подлинности, конечная точка авторизации создает соответствующие токены и перенаправляет браузер назад в конечную точку обратного вызова входа (/authentication/login-callback).
• Когда приложение Blazor WebAssembly загружает конечную точку обратного вызова входа (/authentication/login-callback), происходит обработка ответа проверки подлинности.
  • Если процесс проверки подлинности завершается успешно, пользователь проходит проверку подлинности и при необходимости перенаправляется по запрошенному исходному защищенному URL-адресу.
  • Если процесс проверки подлинности завершается ошибкой по какой-либо причине, пользователь отправляется на страницу входа сбоем (/authentication/login-failed), где отображается ошибка.

Компонент Authentication

Компонент Authentication (Authentication.razor) обрабатывает операции удаленной проверки подлинности и позволяет приложению выполнять следующие действия:

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

Действия по проверке подлинности, такие как регистрация или вход пользователя в систему, передаются в компонент RemoteAuthenticatorViewCore<TAuthenticationState> платформы Blazor, который сохраняет и контролирует состояние в операциях проверки подлинности.

Дополнительные сведения и примеры см. статье Сценарии обеспечения дополнительной безопасности ASP.NET Core Blazor WebAssembly.

Авторизация

В приложениях Blazor WebAssembly авторизацию можно обойти, так как пользователь может изменять весь код на стороне клиента. Это же справедливо для всех технологий на стороне клиента, включая платформы одностраничного приложения JavaScript или собственных приложений для любой операционной системы.

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

Настройка проверки подлинности

Blazor WebAssembly предоставляет методы для добавления и извлечения дополнительных параметров базовой библиотеки проверки подлинности для выполнения удаленных операций проверки подлинности с внешними поставщиками удостоверений.

Для передачи дополнительных параметров NavigationManager поддерживает передачу и получение состояния входа журнала при изменении внешнего расположения. Дополнительные сведения см. на следующих ресурсах:

• BlazorОсновные сведения о>маршрутизации и навигации
  • Состояние журнала навигации
  • Параметры навигации
• Документация по MDN: API журнала

Состояние, хранящееся API журнала, обеспечивает следующие преимущества для удаленной проверки подлинности:

• Состояние, переданное защищенной конечной точке приложения, привязано к навигации, выполняемой для проверки подлинности пользователя в конечной точке authentication/login.
• Не рекомендуется использовать дополнительную кодировку и декодирование данных.
• Область поверхности атаки уменьшается. В отличие от использования строки запроса для хранения состояния навигации, навигация верхнего уровня или влияние из другого источника не может задать состояние, сохраненное API журнала.
• Запись журнала заменяется при успешной проверке подлинности, поэтому состояние, подключенное к записи журнала, удаляется и не требует очистки.

InteractiveRequestOptions представляет запрос к поставщику удостоверений для входа или подготовки маркера доступа.

NavigationManagerExtensions предоставляет метод NavigateToLogin для операции входа и NavigateToLogout для операции выхода. Методы вызывают NavigationManager.NavigateTo, устанавливая состояние записи журнала с помощью переданного InteractiveRequestOptions или нового экземпляра InteractiveRequestOptions, созданного методом, в следующих случаях:

• Пользователь входит (InteractionType.SignIn) с текущим универсальным кодом ресурса (URI) для URL-адреса возврата.
• Пользователь выходит (InteractionType.SignOut) с URL-адресом возврата.

Следующие сценарии проверки подлинности рассматриваются в статье ASP.NET Core: Blazor WebAssembly — дополнительные сценарии безопасности:

• Настройка процесса входа
• Выход с настраиваемым URL-адресом возврата
• Настройка параметров перед интерактивным получением маркера
• Настройка параметров при использовании IAccessTokenProvider
• Получение пути входа из параметров проверки подлинности

Требование авторизации для всего приложения

Примените атрибут (документацию по API) к каждому Razor компоненту [Authorize] приложения с помощью одного из следующих подходов:

• В файле импорта приложения добавьте директиву @using для пространства имен Microsoft.AspNetCore.Authorization с директивой @attribute для атрибута [Authorize].

  _Imports.razor:

  @using Microsoft.AspNetCore.Authorization
  @attribute [Authorize]
  

  Разрешить анонимный Authentication доступ к компоненту, чтобы разрешить перенаправление поставщику удостоверений. Добавьте следующий код Razor в компонент Authentication в его директиве @page.

  Authentication.razor:

  @using Microsoft.AspNetCore.Components.WebAssembly.Authentication
  @attribute [AllowAnonymous]
  

• Добавьте атрибут к каждому Razor компоненту в директиве @page :

  @using Microsoft.AspNetCore.Authorization
  @attribute [Authorize]
  

Примечание.

Задание политики AuthorizationOptions.FallbackPolicy с использованием RequireAuthenticatedUserне поддерживается.

Использование одной регистрации приложения поставщика удостоверений для каждого приложения

Некоторые статьи, приведенные в этом обзоре , относятся к Blazor сценариям размещения, которые включают два или более приложений. Автономное Blazor WebAssembly приложение использует веб-API с прошедшими проверку подлинности пользователями для доступа к ресурсам сервера и данным, предоставляемым серверным приложением.

При реализации этого сценария в примерах документации используются две регистрации поставщика удостоверений, одна для клиентского приложения и одна для серверного приложения. Использование отдельных регистраций, например в идентификаторе Microsoft Entra, не является строго обязательным. Однако использование двух регистраций — это рекомендация по обеспечению безопасности, так как она изолирует регистрации по приложению. Использование отдельных регистраций также позволяет независимо настраивать регистрацию клиента и сервера.

маркеры обновления.

Хотя маркеры обновления не могут быть защищены в Blazor WebAssembly приложениях, их можно использовать, если вы реализуете их с соответствующими стратегиями безопасности.

Для автономных Blazor WebAssembly приложений в ASP.NET Core в .NET 6 или более поздней версии рекомендуется использовать следующее:

• Поток кода авторизации OAuth 2.0 (код) с ключом проверки подлинности для Обмена кодом (PKCE).
• Маркер обновления с коротким сроком действия.
• Повернутый маркер обновления.
• Маркер обновления с истечением срока действия, после которого требуется новый интерактивный поток авторизации для обновления учетных данных пользователя.

Дополнительные сведения см. на следующих ресурсах:

• платформа удостоверений Майкрософт маркеры обновления: время существования маркера обновления
• OAuth 2.0 для приложений на основе браузера (спецификация IETF)

Создание утверждений для пользователей

Приложения часто требуют утверждений для пользователей при вызове сервера в веб-API. Например, утверждения часто используются в приложении для получения авторизации. В этих сценариях приложение запрашивает маркер доступа для доступа к службе и использует маркер для получения пользовательских данных для создания утверждений.

Для примера см. следующие ресурсы:

• Дополнительные сценарии. Настройка пользователя
• ASP.NET Core Blazor WebAssembly с группами и ролями идентификаторов Microsoft Entra

Поддержка предварительной подготовки

Предварительная отрисовка не поддерживается для конечных точек проверки подлинности (сегмент пути /authentication/).

Дополнительные сведения см. в статье Сценарии обеспечения дополнительной безопасности для ASP.NET Core Blazor WebAssembly.

Служба приложений Azure в Linux с сервером Identity

При развертывании в Службе приложений Azure в Linux с сервером Identity нужно указать издателя явно.

Дополнительные сведения см. в статье "Защита Identity серверной части веб-API для spAs".

Проверка подлинности Windows

Не рекомендуется использовать проверку подлинности Windows с Blazor Webassembly или с любой другой платформой SPA. Вместо проверки подлинности Windows рекомендуется использовать протоколы на основе маркеров, такой как OIDC со службами федерации Active Directory (ADFS).

Если проверка подлинности Windows используется с Blazor Webassembly или с любой другой платформой SPA, необходимо принять дополнительные меры для защиты приложения от маркеров подделки межсайтовых запросов (CSRF). Те же проблемы, которые применяются к cookieпроверке подлинности Windows, с добавлением, что проверка подлинности Windows не предоставляет механизм для предотвращения совместного использования контекста проверки подлинности в источниках. Приложения, использующие проверку подлинности Windows без дополнительной защиты от CSRF, должны быть по крайней мере ограничены интрасетью организации и не используются в открытом Интернете.

Дополнительные сведения см. на странице Предотвращение атак с использованием подделки межсайтовых запросов (XSRF/CSRF) в ASP.NET Core.

Защита концентратора SignalR

Чтобы защитить SignalR концентратор в проекте API сервера, примените [Authorize] атрибут к классу концентратора или к методам класса концентратора.

В клиентском проекте с предварительной отрисовкой, например размещенной Blazor WebAssembly (ASP.NET Core в .NET 7 или более ранней версии) или Blazor веб-приложением (ASP.NET Core в .NET 8 или более поздней версии), ознакомьтесь с рекомендациями по ASP.NET CoreBlazorSignalR.

В компоненте клиентского проекта без предварительной подготовки, например автономных Blazor WebAssemblyприложений или приложений, отличных от браузера, предоставьте маркер доступа для подключения к концентратору, как показано в следующем примере. Дополнительные сведения см. в разделе Проверка подлинности и авторизация в ASP.NET Core SignalR.

@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@inject IAccessTokenProvider TokenProvider
@inject NavigationManager Navigation

...

var tokenResult = await TokenProvider.RequestAccessToken();

if (tokenResult.TryGetToken(out var token))
{
    hubConnection = new HubConnectionBuilder()
        .WithUrl(Navigation.ToAbsoluteUri("/chathub"), 
            options => { options.AccessTokenProvider = () => Task.FromResult(token?.Value); })
        .Build();

  ...
}

Ведение журнала

Этот раздел относится к приложениям Blazor WebAssembly в ASP.NET Core в .NET 7 или более поздней версии.

Чтобы включить ведение журнала отладки или трассировки, см. раздел ведения журнала проверки подлинности (Blazor WebAssembly) в статье 7.0 или более поздней версии статьи по ведению журнала ASP.NET CoreBlazor.

Песочница WebAssembly

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

WebAssembly не принадлежит или поддерживается корпорацией Майкрософт.

Дополнительные сведения см. в следующих ресурсах W3C:

• WebAssembly: безопасность
• Спецификация WebAssembly: вопросы безопасности
• Группа сообщества W3C WebAssembly: отзывы и проблемы: ссылка на группу сообщества W3C WebAssembly предоставляется только для справки, что ясно, что уязвимости и ошибки безопасности WebAssembly исправляются постоянно, часто сообщались и устранялись браузером. Не отправляйте отзывы или отчеты об ошибках в группу сообщества W3C WebAssembly.Blazor Отзывы следует отправлять в Blazor подразделение продуктов Microsoft ASP.NET Core. Если подразделение продуктов Майкрософт определяет, что основная проблема с WebAssembly существует, они принимают соответствующие меры, чтобы сообщить о проблеме группе сообщества W3C WebAssembly.

Методические указания по внедрению

Статьи в этом обзоре содержат сведения о проверке подлинности пользователей в приложениях Blazor WebAssembly для конкретных поставщиков.

Автономные приложения Blazor WebAssembly:

• Общие рекомендации по использованию поставщиков OIDC и библиотеки проверки подлинности WebAssembly
• Учетные записи Майкрософт
• Идентификатор Microsoft Entra (ME-ID)
• Azure Active Directory (AAD) B2C

Дополнительное руководство по конфигурации см. в следующих статьях:

• Сценарии обеспечения дополнительной безопасности ASP.NET Core Blazor WebAssembly
• Использование API Graph в ASP.NET Core Blazor WebAssembly

Использование потока кода авторизации с PKCE

платформа удостоверений МайкрософтБиблиотека проверки подлинности Майкрософт для JavaScript версии 2.0 или более поздней версии предоставляет поддержку потока кода авторизации с ключом проверки подлинности для Exchange (PKCE) и межстраничным доступом к ресурсам (CORS) для одностраничных приложений, в том числеBlazor.

Корпорация Майкрософт не рекомендует использовать неявное предоставление.

Дополнительные сведения см. на следующих ресурсах:

• Поддержка потока проверки подлинности в MSAL: неявное предоставление
• платформа удостоверений Майкрософт и неявный поток предоставления: предпочитать поток кода проверки подлинности
• Поток кода авторизации OAuth 2.0 и платформа удостоверений Майкрософт

Дополнительные ресурсы

• документация по платформа удостоверений Майкрософт
  • Общая документация
  • Маркеры доступа в Azure Active Directory
• Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки
  • Использование ПО промежуточного слоя перенаправленных заголовков для сохранения сведений о схеме HTTPS на прокси-серверах и во внутренних сетях.
  • Дополнительные сценарии и варианты использования, включая ручную настройку схемы, изменение пути запроса для правильной маршрутизации запроса и перенаправление схемы запроса для обратных прокси-серверов Linux и обратных прокси-серверов, отличных от IIS.
• Предварительная подготовка с проверкой подлинности
• WebAssembly: безопасность
• Спецификация WebAssembly: вопросы безопасности