Ler em inglês

Partilhar via

Proteja o ASP.NET Core Blazor WebAssembly

  • Artigo

Nota

Esta não é a versão mais recente deste artigo. Para a versão atual, consulte a versão .NET 9 deste artigo.

Aviso

Esta versão do ASP.NET Core não é mais suportada. Para obter mais informações, consulte a Política de suporte do .NET e .NET Core. Para a versão atual, consulte a versão .NET 9 deste artigo.

Importante

Estas informações referem-se a um produto de pré-lançamento que pode ser substancialmente modificado antes de ser lançado comercialmente. A Microsoft não oferece garantias, expressas ou implícitas, em relação às informações fornecidas aqui.

Para a versão atual, consulte a versão .NET 9 deste artigo.

Blazor WebAssembly aplicativos são protegidos da mesma maneira que os aplicativos de página única (SPAs). Existem várias abordagens para autenticar usuários em SPAs, mas a abordagem mais comum e abrangente é usar uma implementação baseada no protocolo OAuth 2.0 , como OpenID Connect (OIDC).

A documentação de segurança Blazor WebAssembly se concentra principalmente em como realizar tarefas de autenticação e autorização do usuário. Para obter a cobertura geral do conceito OAuth 2.0/OIDC, consulte os recursos na seção Recursos adicionais do artigo principal de visão geral.

Segurança do lado do cliente/SPA de dados e credenciais confidenciais

A base de código .NET/C# de um aplicativo Blazor WebAssembly é servida aos clientes e o código do aplicativo não pode ser protegido contra inspeção e adulteração pelos usuários. Nunca coloque dados confidenciais em um aplicativo Blazor WebAssembly, como segredos de aplicativo, cadeias de conexão, senhas, chaves de segurança e código .NET/C# privado.

As seguintes tecnologias são úteis para armazenar dados confidenciais, que podem ser usados juntos no mesmo aplicativo para dividir as responsabilidades de armazenamento de dados entre ambientes de desenvolvimento e preparação/produção:

  • ferramenta Secret Manager: Utilizada apenas no sistema de desenvolvimento local.
  • Azure Key Vault: Pode ser usado para aplicativos executados localmente no ambiente de desenvolvimento e para implantações de preparação/produção.

Para obter exemplos das abordagens anteriores, consulte Confirmação de conta e recuperação de senha no ASP.NET Core Blazor WebAssembly com ASP.NET Core Identity.

Solicitações de API da Web

Para proteger o código e os dados do .NET/C#, use os recursos do ASP.NET Core Data Protection com uma API Web de ASP.NET Core no back-end do lado do servidor. O aplicativo Blazor WebAssembly do lado do cliente chama a API da Web do lado do servidor para recursos seguros do aplicativo e processamento de dados. Para obter mais informações, consulte Chamar uma API da Web de uma aplicação do ASP.NET CoreBlazor e os artigos e exemplos nesta documentação.

Blazor WebAssembly aplicativos geralmente são impedidos de fazer chamadas diretas entre origens para APIs da Web devido a de segurança do CORS (Cross-Origin Request Sharing). Uma exceção típica tem a seguinte aparência:

Acesso à busca em '{URL}' da origem 'https://localhost:{PORT}' foi bloqueado pela política CORS: Nenhum cabeçalho 'Access-Control-Allow-Origin' está presente no recurso solicitado. Se uma resposta opaca atender às suas necessidades, defina o modo da solicitação como 'no-cors' para buscar o recurso com o CORS desativado.

Mesmo que você chame SetBrowserRequestMode com um campo BrowserRequestMode de NoCors (1) buscando contornar a exceção anterior, a solicitação geralmente falha devido a restrições CORS na origem da API da Web, como uma restrição que só permite chamadas de determinada origem ou impede solicitações de JavaScript fetch de um navegador. A única maneira de essas chamadas serem bem-sucedidas é que a API da Web que você está chamando permita que sua origem chame sua origem com a configuração CORS correta. A maioria das APIs da Web externas não permite que você configure suas políticas de CORS. Para lidar com essa restrição, adote uma das seguintes estratégias:

  • Mantenha a sua própria API Web de back-end ASP.NET Core do lado do servidor. O aplicativo Blazor WebAssembly do lado do cliente chama sua API da Web do lado do servidor e sua API da Web faz a solicitação de seu código C# baseado em servidor (não um navegador) para a API da Web externa com os cabeçalhos CORS corretos, retornando o resultado para seu aplicativo Blazor WebAssembly do lado do cliente.

  • Utilize um serviço de proxy para encaminhar a solicitação do aplicativo cliente Blazor WebAssembly para a API externa da Web. O serviço de proxy usa um aplicativo do lado do servidor para fazer a solicitação em nome do cliente e retorna o resultado depois que a chamada é bem-sucedida. No exemplo a seguir, com base no CORS PROXY doCloudFlare, o espaço reservado {REQUEST URI} é o URI da solicitação:

    razor 
    @using System.Net
@inject IHttpClientFactory ClientFactory

...

@code {
    public async Task CallApi()
    {
        var client = ClientFactory.CreateClient();

        var urlEncodedRequestUri = WebUtility.UrlEncode("{REQUEST URI}");

        var request = new HttpRequestMessage(HttpMethod.Get, 
            $"https://corsproxy.io/?{urlEncodedRequestUri}");

        var response = await client.SendAsync(request);

        ...
    }
}

Biblioteca de autenticação

Blazor WebAssembly oferece suporte à autenticação e autorização de aplicativos usando OIDC por meio da biblioteca Microsoft.AspNetCore.Components.WebAssembly.Authentication usando a plataforma de identidade Microsoft. A biblioteca fornece um conjunto de primitivos para autenticação direta em back-ends ASP.NET Core. A biblioteca pode autenticar em qualquer provedor de Identity (IP) de terceiros que suporte OIDC, que são chamados de provedores OpenID (OP).

O suporte à autenticação na Biblioteca de Blazor WebAssembly (Authentication.js) é baseado na Microsoft Authentication Library (MSAL, msal.js), que é usada para lidar com os detalhes do protocolo de autenticação subjacente. A Biblioteca de Blazor WebAssembly suporta apenas o fluxo de código de autorização PKCE (Proof Key for Code Exchange). A subvenção implícita não é suportada.

Existem outras opções para autenticar SPAs, como o uso de cookies SameSite. No entanto, o projeto de engenharia do Blazor WebAssembly usa OAuth e OIDC como a melhor opção para autenticação em aplicativos Blazor WebAssembly. de autenticação baseada em JSON Web Tokens (JWTs) foi escolhida em vez de de autenticação baseada emcookiepor motivos funcionais e de segurança:

  • O uso de um protocolo baseado em token oferece menos vulnerabilidades, pois os tokens não são enviados em todas as solicitações.
  • Os tokens são enviados explicitamente para o servidor, portanto, os pontos de extremidade do servidor não exigem proteção contra CSRF (Cross-Site Request Forgery). Isso permite que você hospede aplicativos Blazor WebAssembly ao lado de aplicativos MVC ou Razor pages.
  • Os tokens têm permissões mais restritas do que os cookies. Por exemplo, os tokens não podem ser usados para gerenciar a conta de usuário ou alterar a senha de um usuário, a menos que essa funcionalidade seja explicitamente implementada.
  • Os tokens têm uma vida útil curta, de uma hora, o que limita a janela de ataque. Os tokens também podem ser revogados a qualquer momento.
  • JWTs independentes oferecem garantias ao cliente e ao servidor sobre o processo de autenticação. Por exemplo, um cliente tem os meios para detetar e validar que os tokens que recebe são legítimos e foram emitidos como parte de um determinado processo de autenticação. Se um terceiro tentar mudar um token no meio do processo de autenticação, o cliente poderá detetar o token comutado e evitar usá-lo.
  • Os tokens com OAuth e OIDC não dependem do comportamento correto do agente do usuário para garantir que o aplicativo seja seguro.
  • Protocolos baseados em tokens, como OAuth e OIDC, permitem autenticar e autorizar usuários em aplicativos autônomos Blazor Webassembly com o mesmo conjunto de características de segurança.
  • O uso de um protocolo baseado em token oferece menos vulnerabilidades, pois os tokens não são enviados em todas as solicitações.
  • Os tokens são enviados explicitamente para o servidor, portanto, os pontos de extremidade do servidor não exigem proteção contra Cross-Site Request Forgery (CSRF). Isso permite que você hospede aplicativos Blazor WebAssembly ao lado de aplicativos MVC ou Razor pages.
  • Os tokens têm permissões mais restritas do que os cookies. Por exemplo, os tokens não podem ser usados para gerenciar a conta de usuário ou alterar a senha de um usuário, a menos que essa funcionalidade seja explicitamente implementada.
  • Os tokens têm uma vida útil curta, de uma hora, o que limita a janela de ataque. Os tokens também podem ser revogados a qualquer momento.
  • JWTs independentes oferecem garantias ao cliente e ao servidor sobre o processo de autenticação. Por exemplo, um cliente tem os meios para detetar e validar que os tokens que recebe são legítimos e foram emitidos como parte de um determinado processo de autenticação. Se um terceiro tentar mudar um token no meio do processo de autenticação, o cliente poderá detetar o token comutado e evitar usá-lo.
  • Os tokens com OAuth e OIDC não dependem do comportamento correto do agente do usuário para garantir que o aplicativo seja seguro.
  • Protocolos baseados em tokens, como OAuth e OIDC, permitem autenticar e autorizar usuários de clientes de solução de Blazor WebAssembly hospedados e aplicativos Blazor Webassembly autônomos com o mesmo conjunto de características de segurança.

Importante

Para versões do ASP.NET Core que adotam o Duende Identity Server em modelos de projeto Blazor, Duende Software pode exigir que você pague uma taxa de licença pelo uso de produção do Duende Identity Server. Para obter mais informações, consulte migrar do ASP.NET Core 5.0 para o6.0 .

Processo de autenticação com OIDC

A biblioteca Microsoft.AspNetCore.Components.WebAssembly.Authentication oferece várias primitivas para implementar autenticação e autorização usando OIDC. Em termos gerais, a autenticação funciona da seguinte forma:

  • Quando um usuário anônimo seleciona o botão de login ou solicita um componente ou página Razor com o atributo [Authorize] aplicado, o usuário é redirecionado para a página de login do aplicativo (/authentication/login).
  • Na página de login, a biblioteca de autenticação prepara-se para um redirecionamento para o endpoint de autorização. O endpoint de autorização está fora da aplicação Blazor WebAssembly e pode estar hospedado em uma origem separada. O ponto de extremidade é responsável por determinar se o usuário está autenticado e por emitir um ou mais tokens em resposta. A biblioteca de autenticação disponibiliza um callback de login para receber a resposta de autenticação.
    • Se o usuário não for autenticado, ele será redirecionado para o sistema de autenticação subjacente, que geralmente é ASP.NET Core Identity.
    • Se o utilizador já estava autenticado, o endpoint de autorização gera os tokens apropriados e redireciona o navegador de volta para o endpoint de retorno de chamada de login (/authentication/login-callback).
  • Quando a aplicação Blazor WebAssembly carrega o endpoint de callback de login (/authentication/login-callback), a resposta de autenticação é processada.
    • Se o processo de autenticação for concluído com êxito, o usuário será autenticado e, opcionalmente, enviado de volta para a URL protegida original que o usuário solicitou.
    • Se o processo de autenticação falhar por qualquer motivo, o usuário será enviado para a página de falha de login (/authentication/login-failed), onde um erro é exibido.

componente Authentication

O componente Authentication (Authentication.razor) lida com operações de autenticação remota e permite que o aplicativo:

  • Configure as rotas das aplicações para os estados de autenticação.
  • Defina o conteúdo da UI para estados de autenticação.
  • Gerencie o estado de autenticação.

As ações de autenticação, como registar ou autenticar um utilizador, são passadas para o componente RemoteAuthenticatorViewCore<TAuthenticationState> da estrutura Blazor, que persiste e controla o estado nas operações de autenticação.

Para obter mais informações e exemplos, consulte ASP.NET Core Blazor WebAssembly cenários de segurança adicionais.

Autorização

Em aplicativos Blazor WebAssembly, as verificações de autorização podem ser ignoradas porque todo o código do lado do cliente pode ser modificado pelos usuários. O mesmo vale para todas as tecnologias de aplicativos do lado do cliente, incluindo estruturas de SPA JavaScript ou aplicativos nativos para qualquer sistema operacional.

Execute sempre verificações de autorização no servidor em qualquer endpoint de API acedido pela sua aplicação do lado do cliente.

Personalizar a autenticação

Blazor WebAssembly fornece métodos para adicionar e recuperar parâmetros adicionais para a biblioteca de autenticação subjacente para conduzir operações de autenticação remota com provedores de identidade externos.

Para passar parâmetros adicionais, o NavigationManager oferece suporte à passagem e recuperação do estado de entrada do histórico ao executar alterações de local externo. Para obter mais informações, consulte os seguintes recursos:

O estado armazenado pela API de histórico fornece os seguintes benefícios para autenticação remota:

  • O estado passado para o endpoint do aplicativo seguro está vinculado à navegação realizada para autenticar o utilizador no endpoint authentication/login.
  • Evita-se trabalho extra de codificação e decodificação de dados.
  • As vulnerabilidades são reduzidas. Ao contrário de usar a cadeia de caracteres de consulta para armazenar o estado de navegação, uma navegação de nível superior ou influência de uma origem diferente não pode definir o estado armazenado pela API de histórico.
  • A entrada do histórico é substituída após a autenticação bem-sucedida, portanto, o estado anexado à entrada do histórico é removido e não requer limpeza.

InteractiveRequestOptions representa a solicitação ao provedor de identidade para efetuar login ou provisionar um token de acesso.

NavigationManagerExtensions fornece o método NavigateToLogin para uma operação de login e NavigateToLogout para uma operação de logout. Os métodos chamam NavigationManager.NavigateTo, definindo o estado de entrada do histórico com uma instância de InteractiveRequestOptions passada ou uma nova instância de InteractiveRequestOptions criada pelo método para:

Os seguintes cenários de autenticação são abordados no ASP.NET Core Blazor WebAssembly cenários de segurança adicionais artigo:

  • Personalizar o processo de login
  • Sair com um endereço de retorno personalizado
  • Personalize as opções antes de obter um token interativamente
  • Personalizar opções ao usar um IAccessTokenProvider
  • Obter o caminho de login a partir das opções de autenticação

Exigir autorização para todo o aplicativo

Aplique o atributo [Authorize] (documentação da API) a cada componente Razor da aplicação usando uma das seguintes abordagens:

  • No arquivo Imports do aplicativo, adicione uma diretiva @using para o namespace Microsoft.AspNetCore.Authorization com uma diretiva @attribute para o atributo [Authorize].

    _Imports.razor:

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

    Permita acesso anônimo ao componente Authentication para permitir o redirecionamento para o provedor de identidade. Adicione o seguinte código Razor ao componente Authentication de acordo com a sua diretiva @page.

    Authentication.razor:

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

  • Adicione o atributo a cada componente Razor sob a diretiva @page:

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

Nota

A definição de um AuthorizationOptions.FallbackPolicy para uma política com RequireAuthenticatedUsernão é suportada.

Usar um registo de aplicação de fornecedor de identidade por aplicação

Alguns dos artigos desta Visão geral dizem respeito a cenários de hospedagem Blazor que envolvem dois ou mais aplicativos. Um aplicativo Blazor WebAssembly autônomo usa a API da Web com usuários autenticados para acessar recursos do servidor e dados fornecidos por um aplicativo de servidor.

Quando esse cenário é implementado em exemplos de documentação, dois registros de provedor de identidade são usados, um para o aplicativo cliente e outro para o aplicativo servidor. O uso de registros separados, por exemplo, no Microsoft Entra ID, não é estritamente necessário. No entanto, usar dois registros é uma prática recomendada de segurança porque isola os registros por aplicativo. O uso de registros separados também permite a configuração independente dos registros do cliente e do servidor.

Alguns dos artigos desta Visão geral pertencem a um dos seguintes cenários de hospedagem Blazor que envolvem dois ou mais aplicativos:

  • Uma solução de Blazor WebAssembly hospedada, que é composta por dois aplicativos: um aplicativo Blazor WebAssembly do lado do cliente e um aplicativo host ASP.NET Core do lado do servidor. Os usuários autenticados no aplicativo cliente acessam os recursos do servidor e os dados fornecidos pelo aplicativo do servidor.
  • Um aplicativo Blazor WebAssembly autônomo que usa a API da Web com usuários autenticados para acessar recursos e dados do servidor fornecidos por um aplicativo de servidor. Este cenário é semelhante ao uso de uma solução de Blazor WebAssembly hospedada; Mas, nesse caso, o aplicativo cliente não é hospedado pelo aplicativo do servidor.

Quando esses cenários são implementados em exemplos de documentação, dois registros de provedor de identidade são usados, um para o aplicativo cliente e outro para o aplicativo servidor. O uso de registros separados, por exemplo, no Microsoft Entra ID, não é estritamente necessário. No entanto, usar dois registros é uma prática recomendada de segurança porque isola os registros por aplicativo. O uso de registros separados também permite a configuração independente dos registros do cliente e do servidor.

Atualizar tokens

Embora os tokens de atualização não possam ser protegidos em aplicativos Blazor WebAssembly, eles podem ser usados se você implementá-los com estratégias de segurança apropriadas.

Para aplicativos Blazor WebAssembly autônomos no ASP.NET Core no .NET 6 ou posterior, recomendamos o uso:

Para soluções de Blazor WebAssembly hospedadas, os tokens de atualização podem ser mantidos e usados pelo aplicativo do lado do servidor para acessar APIs de terceiros. Para obter mais informações, consulte ASP.NET Core Blazor WebAssembly cenários de segurança adicionais.

Para obter mais informações, consulte os seguintes recursos:

Estabelecer declarações para usuários

Os aplicativos geralmente exigem declarações para os usuários com base em uma chamada de API da Web para um servidor. Por exemplo, as declarações são frequentemente usadas para estabelecer autorização em uma aplicação. Nesses cenários, o aplicativo solicita um token de acesso para acessar o serviço e usa o token para obter dados do usuário para criar declarações.

Para obter exemplos, consulte os seguintes recursos:

Suporte de pré-renderização

A prérenderização não é suportada para endpoints de autenticação (no segmento de caminho/authentication/).

de pré-renderização não é suportada para pontos de extremidade de autenticação (segmento de caminho/authentication/).

Para obter mais informações, consulte ASP.NET Core Blazor WebAssembly cenários de segurança adicionais.

Serviço de Aplicativo do Azure no Linux com Identity Server

Especifique o emissor explicitamente ao implantar no Azure App Service no Linux com o Identity Server.

Para obter mais informações, consulte Usar Identity para proteger um back-end de API da Web para SPAs.

Autenticação do Windows

Não recomendamos o uso da Autenticação do Windows com Blazor Webassembly ou com qualquer outra estrutura SPA. Recomendamos o uso de protocolos baseados em tokens em vez da Autenticação do Windows, como o OIDC com os Serviços de Federação do Ative Directory (ADFS).

Se a Autenticação do Windows for usada com Blazor WebAssembly ou com qualquer outra estrutura SPA, serão necessárias medidas adicionais para proteger a aplicação contra tokens de falsificação de pedidos entre sites (CSRF). As mesmas preocupações que se aplicam aos cookies se aplicam à Autenticação do Windows, com a adição de que a Autenticação do Windows não oferece um mecanismo para impedir o compartilhamento do contexto de autenticação entre origens. Os aplicativos que usam a Autenticação do Windows sem proteção adicional da CSRF devem, pelo menos, ser restritos à intranet de uma organização e não devem ser usados na Internet aberta.

Para obter mais informações, consulte Prevenção de ataques Cross-Site Request Forgery (XSRF/CSRF) no ASP.NET Core.

Assegurar um hub SignalR

Para proteger um hub SignalR no projeto de API do servidor, aplique o atributo [Authorize] à classe hub ou aos métodos da classe hub.

Em um projeto cliente com pré-renderização, como Blazor WebAssembly hospedado (ASP.NET Core no .NET 7 ou anterior) ou um Blazor Web App (ASP.NET Core no .NET 8 ou posterior), consulte as orientações no ASP.NET Core BlazorSignalR guidance.

Em um componente de projeto cliente sem pré-renderização, como aplicativos autônomos Blazor WebAssemblyou não navegadores, forneça um token de acesso à conexão de hub, como demonstra o exemplo a seguir. Para obter mais informações, consulte Autenticação e autorização no ASP.NET Core SignalR.

razor 
@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();

  ...
}

Registo

Esta seção se aplica a aplicativos Blazor WebAssembly no ASP.NET Core no .NET 7 ou posterior.

Para habilitar o log de depuração ou rastreamento, consulte a seção Log de autenticação (Blazor WebAssembly) em uma versão 7.0 ou posterior do de log do ASP.NET Core Blazor.

O sandbox do WebAssembly

A sandbox do WebAssembly restringe o acesso ao ambiente do sistema que executa o código WebAssembly, incluindo acesso aos subsistemas de entrada/saída, ao armazenamento e aos recursos do sistema, assim como ao sistema operativo. O isolamento entre o código WebAssembly e o sistema que executa o código torna o WebAssembly uma estrutura de codificação segura para sistemas. No entanto, o WebAssembly é vulnerável a ataques de canal lateral no nível de hardware. Aplicam-se as precauções normais e a devida diligência no fornecimento de hardware e na imposição de limitações no acesso ao hardware.

WebAssembly não pertence nem é mantido pela Microsoft.

Para obter mais informações, consulte os seguintes recursos do W3C:

Orientações para a aplicação

Os artigos desta Visão geral fornecem informações sobre a autenticação de usuários em aplicativos Blazor WebAssembly para provedores específicos.

Aplicações Blazor WebAssembly autónomas:

Outras orientações de configuração encontram-se nos seguintes artigos:

Usar o fluxo de autorização por código com PKCE

O Microsoft Authentication Library for JavaScript (MSAL) v2.0 ou posterior da plataforma de identidade Microsoft fornece suporte para o fluxo de código de autorização com PKCE (Proof Key for Code Exchange) e de compartilhamento de recursos entre origens (CORS) para aplicativos de página única, incluindo Blazor.

A Microsoft não recomenda o uso da concessão implícita.

Para obter mais informações, consulte os seguintes recursos:

Recursos adicionais