Защита ASP.NET Core Blazor WebAssembly
Примечание.
Это не последняя версия этой статьи. В текущем выпуске см . версию .NET 9 этой статьи.
Предупреждение
Эта версия ASP.NET Core больше не поддерживается. Дополнительные сведения см. в статье о политике поддержки .NET и .NET Core. В текущем выпуске см . версию .NET 8 этой статьи.
Внимание
Эта информация относится к предварительному выпуску продукта, который может быть существенно изменен до его коммерческого выпуска. Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, относительно приведенных здесь сведений.
В текущем выпуске см . версию .NET 9 этой статьи.
Защита приложений 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 и статей в этом узле.
Для локального тестирования разработки средство Secret Manager рекомендуется для защиты конфиденциальных данных.
Библиотека проверки подлинности
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 (JWT), была выбрана вместо проверки подлинности на основе файлов cookie.
- Использование протокола на основе маркеров обеспечивает меньше уязвимостей, так как маркеры не отправляются во всех запросах.
- Маркеры явно отправляются на сервер, поэтому конечные точки сервера не требуют защиты от межсайтовых запросов forgery (CSRF). Это позволяет размещать приложения Blazor WebAssembly параллельно с приложениями MVC или Razor Pages.
- Разрешения токенов более узкие, чем разрешения файлов cookie. Например, токены нельзя использовать для управления учетной записью пользователя или изменения пароля пользователя, если такие функции не реализованы явным образом.
- Маркеры имеют короткое время существования, один час, который ограничивает окно атаки. Токены можно отозвать в любое время.
- Автономные токены JWT гарантируют выполнение надлежащего процесса проверки подлинности на клиенте и сервере. Например, на клиенте есть средства для обнаружения и проверки допустимости получаемых токенов, а также подтверждения их выпуска в рамках данного процесса проверки подлинности. Если третья сторона пытается изменить токен в ходе процесса проверки подлинности, клиент может обнаружить измененный токен и не использовать его.
- Токены с OAuth и OIDC обеспечивают безопасность приложения вне зависимости от поведения агента пользователя.
- Протоколы на основе токенов, такие как OAuth и OIDC, позволяют выполнять проверку подлинности и авторизацию пользователей в автономных Blazor приложениях Webassembly с одинаковым набором характеристик безопасности.
- Использование протокола на основе маркеров обеспечивает меньше уязвимостей, так как маркеры не отправляются во всех запросах.
- Маркеры явно отправляются на сервер, поэтому конечные точки сервера не требуют защиты от межсайтовых запросов forgery (CSRF). Это позволяет размещать приложения Blazor WebAssembly параллельно с приложениями MVC или Razor Pages.
- Разрешения токенов более узкие, чем разрешения файлов cookie. Например, токены нельзя использовать для управления учетной записью пользователя или изменения пароля пользователя, если такие функции не реализованы явным образом.
- Маркеры имеют короткое время существования, один час, который ограничивает окно атаки. Токены можно отозвать в любое время.
- Автономные токены JWT гарантируют выполнение надлежащего процесса проверки подлинности на клиенте и сервере. Например, на клиенте есть средства для обнаружения и проверки допустимости получаемых токенов, а также подтверждения их выпуска в рамках данного процесса проверки подлинности. Если третья сторона пытается изменить токен в ходе процесса проверки подлинности, клиент может обнаружить измененный токен и не использовать его.
- Токены с OAuth и OIDC обеспечивают безопасность приложения вне зависимости от поведения агента пользователя.
- Протоколы на основе токенов, такие как OAuth и OIDC, позволяют выполнять проверку подлинности и авторизацию пользователей размещенных Blazor WebAssembly клиентов решений и автономных Blazor приложений Webassembly с одинаковым набором характеристик безопасности.
Внимание
Для версий ASP.NET Core, которые принимают Duende Server в Blazor шаблонах проектов, Duende Software может потребоваться оплатить плату за использование сервера Duende Identity Identity в рабочей среде. Дополнительные сведения см. в статье Миграция с 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 предоставляет методы для добавления и извлечения дополнительных параметров базовой библиотеки проверки подлинности для выполнения удаленных операций проверки подлинности с внешними identity поставщиками.
Для передачи дополнительных параметров NavigationManager поддерживает передачу и получение состояния входа журнала при изменении внешнего расположения. Дополнительные сведения см. на следующих ресурсах:
- BlazorОсновные сведения о>маршрутизации и навигации
- Документация по MDN: API журнала
Состояние, хранящееся API журнала, обеспечивает следующие преимущества для удаленной проверки подлинности:
- Состояние, переданное защищенной конечной точке приложения, привязано к навигации, выполняемой для проверки подлинности пользователя в конечной точке
authentication/login
. - Не рекомендуется использовать дополнительную кодировку и декодирование данных.
- Уязвимости сокращаются. В отличие от использования строки запроса для хранения состояния навигации, навигация верхнего уровня или влияние из другого источника не может задать состояние, сохраненное API журнала.
- Запись журнала заменяется при успешной проверке подлинности, поэтому состояние, подключенное к записи журнала, удаляется и не требует очистки.
InteractiveRequestOptions представляет запрос identity к поставщику для входа в систему или подготовки маркера доступа.
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
доступ к компоненту, чтобы разрешить перенаправление поставщику identity . Добавьте следующий код Razor в компонентAuthentication
в его директиве@page
.Authentication.razor
:@using Microsoft.AspNetCore.Components.WebAssembly.Authentication @attribute [AllowAnonymous]
Добавьте атрибут к каждому Razor компоненту в директиве
@page
:@using Microsoft.AspNetCore.Authorization @attribute [Authorize]
Примечание.
Задание политики AuthorizationOptions.FallbackPolicy с использованием RequireAuthenticatedUser не поддерживается.
Использование одной identity регистрации приложения поставщика для каждого приложения
Некоторые статьи, приведенные в этом обзоре , относятся к Blazor сценариям размещения, которые включают два или более приложений. Автономное Blazor WebAssembly приложение использует веб-API с прошедшими проверку подлинности пользователями для доступа к ресурсам сервера и данным, предоставляемым серверным приложением.
При реализации этого сценария в примерах документации используются двеidentity регистрации поставщика, одна для клиентского приложения и одна для серверного приложения. Использование отдельных регистраций, например в идентификаторе Microsoft Entra, не является строго обязательным. Однако использование двух регистраций — это рекомендация по обеспечению безопасности, так как она изолирует регистрации по приложению. Использование отдельных регистраций также позволяет независимо настраивать регистрацию клиента и сервера.
Некоторые статьи, описанные в этом обзоре , относятся к следующим Blazor сценариям размещения, которые включают два или более приложений:
- Размещенное Blazor WebAssembly решение, состоящее из двух приложений: клиентское Blazor WebAssembly приложение и серверное ASP.NET основное приложение. Пользователи, прошедшие проверку подлинности, получают доступ к ресурсам сервера и данным клиентского приложения, предоставляемым серверным приложением.
- Автономное Blazor WebAssembly приложение, использующее веб-API с прошедшими проверку подлинности пользователями для доступа к ресурсам сервера и данным, предоставляемым серверным приложением. Этот сценарий аналогичен использованию размещенного Blazor WebAssembly решения, но в этом случае клиентское приложение не размещается серверным приложением.
При реализации этих сценариев в примерах документации используются двеidentity регистрации поставщика, одна для клиентского приложения и одна для серверного приложения. Использование отдельных регистраций, например в идентификаторе Microsoft Entra, не является строго обязательным. Однако использование двух регистраций — это рекомендация по обеспечению безопасности, так как она изолирует регистрации по приложению. Использование отдельных регистраций также позволяет независимо настраивать регистрацию клиента и сервера.
маркеры обновления.
Хотя маркеры обновления не могут быть защищены в Blazor WebAssembly приложениях, их можно использовать, если вы реализуете их с соответствующими стратегиями безопасности.
Для автономных Blazor WebAssembly приложений в ASP.NET Core в .NET 6 или более поздней версии рекомендуется использовать следующее:
- Поток кода авторизации OAuth 2.0 (код) с ключом проверки подлинности для Обмена кодом (PKCE).
- Маркер обновления с коротким сроком действия.
- Повернутый маркер обновления.
- Маркер обновления с истечением срока действия, после которого требуется новый интерактивный поток авторизации для обновления учетных данных пользователя.
Для размещенных Blazor WebAssembly решений маркеры обновления можно поддерживать и использовать серверным приложением для доступа к сторонним API. Дополнительные сведения см. в статье Сценарии обеспечения дополнительной безопасности для ASP.NET Core Blazor WebAssembly.
Дополнительные сведения см. на следующих ресурсах:
- Маркеры обновления платформы Майкрософт identity : время существования маркера обновления
- OAuth 2.0 для приложений на основе браузера (спецификация IETF)
Создание утверждений для пользователей
Приложения часто требуют утверждений для пользователей при вызове сервера в веб-API. Например, утверждения часто используются в приложении для получения авторизации. В этих сценариях приложение запрашивает маркер доступа для доступа к службе и использует маркер для получения пользовательских данных для создания утверждений.
Для примера см. следующие ресурсы:
- Дополнительные сценарии. Настройка пользователя
- ASP.NET Core Blazor WebAssembly с группами и ролями идентификаторов Microsoft Entra
Поддержка предварительной подготовки
Предварительная отрисовка не поддерживается для конечных точек проверки подлинности (сегмент пути /authentication/
).
Предварительная отрисовка не поддерживается для конечных точек проверки подлинности (сегмент пути /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 Web App (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
Размещенные приложения Blazor WebAssembly:
Дополнительное руководство по конфигурации см. в следующих статьях:
- Сценарии обеспечения дополнительной безопасности ASP.NET Core Blazor WebAssembly
- Использование API Graph в ASP.NET Core Blazor WebAssembly
Использование потока кода авторизации с PKCE
identity Библиотека проверки подлинности Microsoft platform для JavaScript версии 2.0 или более поздней версии обеспечивает поддержку потока кода авторизации с ключом проверки подлинности для Exchange (PKCE) и межстраничного доступа к ресурсам (CORS) для одностраничных приложений, включаяBlazor.
Корпорация Майкрософт не рекомендует использовать неявное предоставление.
Дополнительные сведения см. на следующих ресурсах:
- Поддержка потока проверки подлинности в MSAL: неявное предоставление
- Платформа Майкрософт identity и поток неявного предоставления: предпочесть поток кода проверки подлинности
- Поток кода авторизации microsoft identity platform и OAuth 2.0
Дополнительные ресурсы
- Документация по платформе Майкрософт identity
- Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки
- Использование ПО промежуточного слоя перенаправленных заголовков для сохранения сведений о схеме HTTPS на прокси-серверах и во внутренних сетях.
- Дополнительные сценарии и варианты использования, включая ручную настройку схемы, изменение пути запроса для правильной маршрутизации запроса и перенаправление схемы запроса для обратных прокси-серверов Linux и обратных прокси-серверов, отличных от IIS.
- Предварительная подготовка с проверкой подлинности
- WebAssembly: безопасность
- Спецификация WebAssembly: вопросы безопасности
ASP.NET Core