Considerações de segurança no ASP.NET Core SignalR

Este artigo fornece informações sobre como proteger SignalR.

O CORS (Cross-Origin Resource Sharing) pode ser usado para permitir conexões entre origens SignalR no navegador. Se o código JavaScript estiver hospedado num domínio diferente do SignalR aplicativo, o middleware CORS deve ser ativado para permitir que o JavaScript estabeleça conexão com o SignalR aplicativo. Permita solicitações de origem cruzada somente de domínios em que você confia ou controla. Por exemplo:

Seu site está hospedado em http://www.example.com
Seu SignalR aplicativo está hospedado em http://signalr.example.com

O CORS deve configurar-se na aplicação SignalR para permitir apenas a origem www.example.com.

Para obter mais informações sobre como configurar o CORS, consulte Habilitar solicitações entre origens (CORS). SignalR requer as seguintes políticas de CORS:

Permitir as origens específicas previstas. Permitir qualquer origem é possível, mas não é seguro ou recomendado.
Os métodos HTTP GET e POST devem ser permitidos.
As credenciais devem ser permitidas para que as sessões adesivas baseadas no cookie funcionem corretamente. Eles devem ser habilitados mesmo quando a autenticação não é usada.

No entanto, na versão 5.0, fornecemos uma opção no cliente TypeScript para não usar credenciais. A opção de não usar credenciais só deve ser usada quando você souber 100% que credenciais como Cookies não são necessárias em seu aplicativo (cookies são usados pelo serviço de aplicativo azure ao usar vários servidores para sessões adesivas).

Por exemplo, a seguinte política CORS realçada permite que um SignalR cliente de navegador hospedado em https://example.com acesse o SignalR aplicativo hospedado em https://signalr.example.com:

using SignalRChat.Hubs;

var MyAllowSpecificOrigins = "_myAllowSpecificOrigins";

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCors(options =>
{
    options.AddPolicy(name: MyAllowSpecificOrigins,
                      policy =>
                      {
                          policy.WithOrigins("http://example.com");
                          policy.WithMethods("GET", "POST");
                          policy.AllowCredentials();
                      });
});

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddSignalR();

var app = builder.Build();

app.MapHub<ChatHub>("/chatHub");

No exemplo anterior, a política CORS é personalizada para permitir origens, métodos e credenciais específicos. Para obter mais informações sobre como personalizar políticas CORS e middleware no ASP.NET Core, consulte CORS middleware: CORS com política nomeada e middleware.

Restrição de origem do WebSocket

As proteções fornecidas pelo CORS não se aplicam a WebSockets. Para restrição de origem em WebSockets, leia Restrição de origem de WebSockets.

ConnectionId

A exposição ConnectionId pode levar a uma representação maliciosa se a versão do SignalR servidor ou cliente for ASP.NET Core 2.2 ou anterior. Se a versão do servidor e do cliente SignalR for ASP.NET Core 3.0 ou posterior, o ConnectionToken em vez do ConnectionId deve ser mantido em segredo. O ConnectionToken não é propositadamente exposto em nenhuma API. Pode ser difícil garantir que os clientes mais antigos SignalR não estejam se conectando ao servidor, portanto, mesmo que sua SignalR versão do servidor seja ASP.NET Core 3.0 ou posterior, a ConnectionId versão não deve ser exposta.

Registo de tokens de acesso

Ao usar WebSockets ou Server-Sent Events, o cliente do browser envia o token de acesso na string de consulta. Receber o token de acesso por meio da cadeia de caracteres de consulta geralmente é tão seguro quanto usar o cabeçalho padrão Authorization . Sempre use HTTPS para garantir uma conexão segura de ponta a ponta entre o cliente e o servidor. Muitos servidores Web registram a URL de cada solicitação, incluindo a cadeia de caracteres de consulta. O registro das URLs pode registrar o token de acesso. ASP.NET Core registra a URL de cada solicitação por padrão, o que inclui a cadeia de caracteres de consulta. Por exemplo:

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/chathub?access_token=1234

Se você tiver preocupações sobre o registro desses dados com os logs do servidor, você pode desativar esse registro inteiramente configurando o Microsoft.AspNetCore.Hosting logger para o Warning nível ou acima (essas mensagens são escritas no Info nível). Para obter mais informações, consulte Aplicar regras de filtro de log no código para obter mais informações. Se ainda quiseres registar determinadas informações de solicitação, podes escrever middleware para registar os dados que necessitas e filtrar o valor da cadeia de consulta access_token (se presente).

Exceções

As mensagens de exceção geralmente são consideradas dados confidenciais que não devem ser revelados a um cliente. Por padrão, SignalR não envia os detalhes de uma exceção lançada por um método de hub para o cliente. Em vez disso, o cliente recebe uma mensagem genérica indicando que ocorreu um erro. A entrega de mensagens de exceção ao cliente pode ser substituída (por exemplo, em desenvolvimento ou teste) por EnableDetailedErrors. As mensagens de exceção não devem ser expostas ao cliente em aplicativos de produção.

Gerenciamento de buffer

SignalR usa buffers por conexão para gerenciar mensagens de entrada e saída. Por padrão, SignalR limita esses buffers a 32 KB. A maior mensagem que um cliente ou servidor pode enviar é de 32 KB. A memória máxima consumida por uma conexão para mensagens é de 32 KB. Se as suas mensagens forem sempre inferiores a 32 KB, pode reduzir o limite, o que:

Impede que um cliente possa enviar uma mensagem maior.
O servidor nunca precisará alocar buffers grandes para aceitar mensagens.

Se as suas mensagens tiverem mais de 32 KB, pode aumentar o limite. Aumentar este limite significa:

O cliente pode fazer com que o servidor aloque buffers de memória grandes.
A alocação do servidor de buffers grandes pode reduzir o número de conexões simultâneas.

Há limites para mensagens de entrada e saída, ambos podem ser configurados no objeto HttpConnectionDispatcherOptions configurado em MapHub:

ApplicationMaxBufferSize representa o número máximo de bytes do cliente que o servidor armazena em buffer. Se o cliente tentar enviar uma mensagem maior que esse limite, a conexão pode ser fechada.
TransportMaxBufferSize representa o número máximo de bytes que o servidor pode enviar. Se o servidor tentar enviar uma mensagem (incluindo valores de retorno de métodos de hub) maior que esse limite, uma exceção será lançada.

Definir o limite para 0 desativar o limite. Remover o limite permite que um cliente envie uma mensagem de qualquer tamanho. Clientes mal-intencionados que enviam mensagens grandes podem fazer com que o excesso de memória seja alocado. O uso excessivo de memória pode reduzir significativamente o número de conexões simultâneas.

Este artigo fornece informações sobre como proteger SignalR.

Seu site está hospedado em http://www.example.com
Seu SignalR aplicativo está hospedado em http://signalr.example.com

O CORS deve configurar-se na aplicação SignalR para permitir apenas a origem www.example.com.

Para obter mais informações sobre como configurar o CORS, consulte Habilitar solicitações entre origens (CORS). SignalR requer as seguintes políticas de CORS:

Permitir as origens específicas previstas. Permitir qualquer origem é possível, mas não é seguro ou recomendado.
Os métodos HTTP GET e POST devem ser permitidos.
As credenciais devem ser permitidas para que as sessões adesivas baseadas no cookie funcionem corretamente. Eles devem ser habilitados mesmo quando a autenticação não é usada.

Por exemplo, a seguinte política CORS realçada permite que um SignalR cliente de navegador hospedado em https://example.com acesse o SignalR aplicativo hospedado em https://signalr.example.com:

using SignalRChat.Hubs;

var MyAllowSpecificOrigins = "_myAllowSpecificOrigins";

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCors(options =>
{
    options.AddPolicy(name: MyAllowSpecificOrigins,
                      policy =>
                      {
                          policy.WithOrigins("http://example.com");
                          policy.WithMethods("GET", "POST");
                          policy.AllowCredentials();
                      });
});

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddSignalR();

var app = builder.Build();

app.MapHub<ChatHub>("/chatHub");

Restrição de origem do WebSocket

As proteções fornecidas pelo CORS não se aplicam a WebSockets. Para restrição de origem em WebSockets, leia Restrição de origem de WebSockets.

ConnectionId

Registo de tokens de acesso

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/chathub?access_token=1234

Exceções

Gerenciamento de buffer

Impede que um cliente possa enviar uma mensagem maior.
O servidor nunca precisará alocar buffers grandes para aceitar mensagens.

Se as suas mensagens tiverem mais de 32 KB, pode aumentar o limite. Aumentar este limite significa:

O cliente pode fazer com que o servidor aloque buffers de memória grandes.
A alocação do servidor de buffers grandes pode reduzir o número de conexões simultâneas.

Há limites para mensagens de entrada e saída, ambos podem ser configurados no objeto HttpConnectionDispatcherOptions configurado em MapHub:

ApplicationMaxBufferSize representa o número máximo de bytes do cliente que o servidor armazena em buffer. Se o cliente tentar enviar uma mensagem maior que esse limite, a conexão pode ser fechada.
TransportMaxBufferSize representa o número máximo de bytes que o servidor pode enviar. Se o servidor tentar enviar uma mensagem (incluindo valores de retorno de métodos de hub) maior que esse limite, uma exceção será lançada.

Este artigo fornece informações sobre como proteger SignalR.

Seu site está hospedado em http://www.example.com
Seu SignalR aplicativo está hospedado em http://signalr.example.com

O CORS deve configurar-se na aplicação SignalR para permitir apenas a origem www.example.com.

Para obter mais informações sobre como configurar o CORS, consulte Habilitar solicitações entre origens (CORS). SignalR requer as seguintes políticas de CORS:

Permitir as origens específicas previstas. Permitir qualquer origem é possível, mas não é seguro ou recomendado.
Os métodos HTTP GET e POST devem ser permitidos.
As credenciais devem ser permitidas para que as sessões adesivas baseadas no cookie funcionem corretamente. Eles devem ser habilitados mesmo quando a autenticação não é usada.

Por exemplo, a seguinte política CORS realçada permite que um SignalR cliente de navegador hospedado em https://example.com acesse o SignalR aplicativo hospedado em https://signalr.example.com:

using SignalRChat.Hubs;

var MyAllowSpecificOrigins = "_myAllowSpecificOrigins";

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCors(options =>
{
    options.AddPolicy(name: MyAllowSpecificOrigins,
                      policy =>
                      {
                          policy.WithOrigins("http://example.com");
                          policy.WithMethods("GET", "POST");
                          policy.AllowCredentials();
                      });
});

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddSignalR();

var app = builder.Build();

app.MapHub<ChatHub>("/chatHub");

Restrição de origem do WebSocket

As proteções fornecidas pelo CORS não se aplicam a WebSockets. Para restrição de origem em WebSockets, leia Restrição de origem de WebSockets.

ConnectionId

Registo de tokens de acesso

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/chathub?access_token=1234

Exceções

Gerenciamento de buffer

Impede que um cliente possa enviar uma mensagem maior.
O servidor nunca precisará alocar buffers grandes para aceitar mensagens.

Se as suas mensagens tiverem mais de 32 KB, pode aumentar o limite. Aumentar este limite significa:

O cliente pode fazer com que o servidor aloque buffers de memória grandes.
A alocação do servidor de buffers grandes pode reduzir o número de conexões simultâneas.

Há limites para mensagens de entrada e saída, ambos podem ser configurados no objeto HttpConnectionDispatcherOptions configurado em MapHub:

ApplicationMaxBufferSize representa o número máximo de bytes do cliente que o servidor armazena em buffer. Se o cliente tentar enviar uma mensagem maior que esse limite, a conexão pode ser fechada.
TransportMaxBufferSize representa o número máximo de bytes que o servidor pode enviar. Se o servidor tentar enviar uma mensagem (incluindo valores de retorno de métodos de hub) maior que esse limite, uma exceção será lançada.

Este artigo fornece informações sobre como proteger SignalR.

Seu site está hospedado em http://www.example.com
Seu SignalR aplicativo está hospedado em http://signalr.example.com

O CORS deve configurar-se na aplicação SignalR para permitir apenas a origem www.example.com.

Para obter mais informações sobre como configurar o CORS, consulte Habilitar solicitações entre origens (CORS). SignalR requer as seguintes políticas de CORS:

Permitir as origens específicas previstas. Permitir qualquer origem é possível, mas não é seguro ou recomendado.
Os métodos HTTP GET e POST devem ser permitidos.
As credenciais devem ser permitidas para que as sessões adesivas baseadas no cookie funcionem corretamente. Eles devem ser habilitados mesmo quando a autenticação não é usada.

Por exemplo, a seguinte política CORS permite que um SignalR cliente de navegador hospedado em https://example.com acesse o SignalR aplicativo hospedado em https://signalr.example.com:

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // ... other middleware ...

    // Make sure the CORS middleware is ahead of SignalR.
    app.UseCors(builder =>
    {
        builder.WithOrigins("https://example.com")
            .AllowAnyHeader()
            .WithMethods("GET", "POST")
            .AllowCredentials();
    });

    // ... other middleware ...
    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapHub<ChatHub>("/chathub");
    });

    // ... other middleware ...
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // ... other middleware ...

    // Make sure the CORS middleware is ahead of SignalR.
    app.UseCors(builder =>
    {
        builder.WithOrigins("https://example.com")
            .AllowAnyHeader()
            .WithMethods("GET", "POST")
            .AllowCredentials();
    });

    // ... other middleware ...

    app.UseSignalR(routes =>
    {
        routes.MapHub<ChatHub>("/chathub");
    });

    // ... other middleware ...
}

Restrição de origem do WebSocket

As proteções fornecidas pelo CORS não se aplicam a WebSockets. Para restrição de origem em WebSockets, leia Restrição de origem de WebSockets.

As proteções fornecidas pelo CORS não se aplicam a WebSockets. Os navegadores não:

Execute solicitações de pré-voo do CORS.
Respeite as restrições especificadas nos Access-Control cabeçalhos ao fazer solicitações WebSocket.

No entanto, os navegadores enviam o Origin cabeçalho ao emitir solicitações WebSocket. Os aplicativos devem ser configurados para validar esses cabeçalhos para garantir que apenas WebSockets provenientes das origens esperadas sejam permitidos.

No ASP.NET Core 2.1 ou posterior, a validação de cabeçalho pode ser obtida usando um middleware personalizado colocado antes UseSignalRe middleware de autenticação em Configure:


// In Startup, add a static field listing the allowed Origin values:
private static readonly HashSet<string> _allowedOrigins = new HashSet<string>()
{
    // Add allowed origins here. For example:
    "https://www.mysite.com",
    "https://mysite.com",
};

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // ... other middleware ...

    // Validate Origin header on WebSocket requests to prevent unexpected cross-site 
    // WebSocket requests.
    app.Use((context, next) =>
    {
        // Check for a WebSocket request.
        if (string.Equals(context.Request.Headers["Upgrade"], "websocket"))
        {
            var origin = context.Request.Headers["Origin"];

            // If there is an origin header, and the origin header doesn't match 
            // an allowed value:
            if (!string.IsNullOrEmpty(origin) && !_allowedOrigins.Contains(origin))
            {
                // The origin is not allowed, reject the request
                context.Response.StatusCode = (int) HttpStatusCode.Forbidden;
                return Task.CompletedTask;
            }
        }

        // The request is a valid Origin or not a WebSocket request, so continue.
        return next();
    });

    // ... other middleware ...

    app.UseSignalR(routes =>
    {
        routes.MapHub<ChatHub>("/chathub");
    });

    // ... other middleware ...
}

Observação

O Origin cabeçalho é controlado pelo cliente e, como o Referer cabeçalho, pode ser falsificado. Esses cabeçalhos não devem ser usados como um mecanismo de autenticação.

ConnectionId

Registo de tokens de acesso

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/chathub?access_token=1234

Exceções

Gerenciamento de buffer

Impede que um cliente possa enviar uma mensagem maior.
O servidor nunca precisará alocar buffers grandes para aceitar mensagens.

Se as suas mensagens tiverem mais de 32 KB, pode aumentar o limite. Aumentar este limite significa:

O cliente pode fazer com que o servidor aloque buffers de memória grandes.
A alocação do servidor de buffers grandes pode reduzir o número de conexões simultâneas.

Há limites para mensagens de entrada e saída, ambos podem ser configurados no objeto HttpConnectionDispatcherOptions configurado em MapHub:

ApplicationMaxBufferSize representa o número máximo de bytes do cliente que o servidor armazena em buffer. Se o cliente tentar enviar uma mensagem maior que esse limite, a conexão pode ser fechada.
TransportMaxBufferSize representa o número máximo de bytes que o servidor pode enviar. Se o servidor tentar enviar uma mensagem (incluindo valores de retorno de métodos de hub) maior que esse limite, uma exceção será lançada.

Feedback

Esta página foi útil?

Last updated on 2025-05-06

Partilhar via

Considerações de segurança no ASP.NET Core SignalR

Compartilhamento de recursos entre origens

Restrição de origem do WebSocket

ConnectionId

Registo de tokens de acesso

Exceções

Gerenciamento de buffer

Compartilhamento de recursos entre origens

Restrição de origem do WebSocket

ConnectionId

Registo de tokens de acesso

Exceções

Gerenciamento de buffer

Compartilhamento de recursos entre origens

Restrição de origem do WebSocket

ConnectionId

Registo de tokens de acesso

Exceções

Gerenciamento de buffer

Compartilhamento de recursos entre origens

Restrição de origem do WebSocket

ConnectionId

Registo de tokens de acesso

Exceções

Gerenciamento de buffer

Feedback

Recursos adicionais