Säkerhetsöverväganden i ASP.NET Core SignalR

2025-05-28

Den här artikeln innehåller information om hur du SignalRskyddar .

Cross-Origin Resource Sharing (CORS) kan användas för att tillåta cross-origin-anslutningar i webbläsaren. Om JavaScript-kod finns på en annan domän än SignalR appen måste CORS-mellanprogrammet vara aktiverat för att JavaScript ska kunna ansluta till SignalR appen. Tillåt endast förfrågningar över ursprung från domäner som du litar på eller kontrollerar. Till exempel:

Webbplatsen finns på http://www.example.com
Din SignalR app finns på http://signalr.example.com

CORS bör konfigureras i SignalR appen för att endast tillåta ursprunget www.example.com.

Mer information om hur du konfigurerar CORS finns i Aktivera CORS (Cross-Origin Requests). SignalR kräver följande CORS-principer:

Tillåt de specifika förväntade källorna. Att tillåta alla ursprung är möjligt, men det är inte säkert eller rekommenderat.
HTTP-metoder GET och POST måste tillåtas.
Autentiseringsuppgifter måste tillåtas för att cookie-baserade persistenta sessioner ska fungera korrekt. De måste vara aktiverade även när autentisering inte används.

I 5.0 har vi dock angett ett alternativ i TypeScript-klienten för att inte använda autentiseringsuppgifter. Alternativet att inte använda autentiseringsuppgifter bör endast användas när du vet 100% att autentiseringsuppgifter som cookies inte behövs i din app (cookies används av Azure App Service när du använder flera servrar för klibbiga sessioner).

Följande markerade CORS-princip tillåter till exempel att en SignalR webbläsarklient som finns på https://example.com får åtkomst till appen som SignalR finns på 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");

I föregående exempel anpassas CORS-principen för att tillåta specifika ursprung, metoder och autentiseringsuppgifter. Mer information om hur du anpassar CORS-principer och mellanprogram i ASP.NET Core finns i CORS-mellanprogram: CORS med namngiven princip och mellanprogram.

Begränsning av WebSocket-ursprung

De skydd som tillhandahålls av CORS gäller inte för WebSockets. För ursprungsbegränsning på WebSockets läser du Ursprungsbegränsning för WebSockets.

ConnectionId

Att exponera ConnectionId kan leda till skadlig personifiering om SignalR servern eller klientversionen är ASP.NET Core 2.2 eller tidigare. Om servern och klientversionen är ASP.NET Core 3.0 eller senare, måste SignalR snarare än ConnectionToken hållas hemligt. ConnectionToken Exponeras avsiktligt inte i något API. Det kan vara svårt att se till att äldre SignalR klienter inte ansluter till servern, så även om serverversionen SignalR är ASP.NET Core 3.0 eller senare bör den ConnectionId inte exponeras.

Loggning av åtkomsttoken

När du använder WebSockets eller Server-Sent Events skickar webbläsarklienten åtkomsttoken i frågesträngen. Att ta emot åtkomsttoken via frågesträngen är vanligtvis lika säkert som att använda standardrubriken Authorization . Använd alltid HTTPS för att säkerställa en säker anslutning från slutpunkt till slutpunkt mellan klienten och servern. Många webbservrar loggar URL:en för varje begäran, inklusive frågesträngen. Att logga URL:er kan logga åtkomsttokenet. ASP.NET Core loggar URL:en för varje begäran som standard, vilket inkluderar frågesträngen. Till exempel:

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

Om du har problem med att logga dessa data med dina serverloggar kan du inaktivera loggningen helt och hållet genom att konfigurera loggaren Microsoft.AspNetCore.Hosting på nivån Warning eller högre (dessa meddelanden skrivs på Info nivå). Mer information finns i Tillämpa loggfilterregler i kod för mer information. Om du fortfarande vill logga viss information om begäran kan du skriva mellanprogram för att logga de data som du behöver och filtrera bort frågesträngsvärdet (om det access_token finns).

Undantag

Undantagsmeddelanden betraktas vanligtvis som känsliga data som inte ska visas för en klient. Som standard SignalR skickar inte informationen om ett undantag som genereras av en hubbmetod till klienten. I stället får klienten ett allmänt meddelande som anger att ett fel har uppstått. Undantagsmeddelandeleverans till klienten kan åsidosättas (till exempel under utveckling eller test) med EnableDetailedErrors. Undantagsmeddelanden ska inte exponeras för klienten i produktionsappar.

Bufferthantering

SignalR använder buffertar per anslutning för att hantera inkommande och utgående meddelanden. Som standard SignalR begränsar dessa buffertar till 32 KB. Det största meddelandet som en klient eller server kan skicka är 32 KB. Det maximala minne som förbrukas av en anslutning för meddelanden är 32 KB. Om dina meddelanden alltid är mindre än 32 KB kan du minska gränsen, vilket:

Förhindrar att en klient kan skicka ett större meddelande.
Servern behöver aldrig allokera stora buffertar för att acceptera meddelanden.

Om dina meddelanden är större än 32 KB kan du öka gränsen. Om du ökar den här gränsen innebär det att:

Klienten kan göra så att servern allokerar stora minnesbuffertar.
Serverallokering av stora buffertar kan minska antalet samtidiga anslutningar.

Det finns gränser för inkommande och utgående meddelanden, båda kan konfigureras för objektet HttpConnectionDispatcherOptions som konfigurerats i MapHub:

ApplicationMaxBufferSize representerar det maximala antalet byte från klienten som servern buffrar. Om klienten försöker skicka ett meddelande som är större än den här gränsen kan anslutningen stängas.
TransportMaxBufferSize representerar det maximala antalet byte som servern kan skicka. Om servern försöker skicka ett meddelande (inklusive returvärden från hubbmetoder) som är större än den här gränsen utlöses ett undantag.

Om du anger gränsen till 0 inaktiveras gränsen. Om du tar bort gränsen kan en klient skicka ett meddelande av valfri storlek. Skadliga klienter som skickar stora meddelanden kan orsaka att överflödigt minne allokeras. Överförbrukning av minne kan avsevärt minska antalet samtidiga anslutningar.

Den här artikeln innehåller information om hur du SignalRskyddar .

Webbplatsen finns på http://www.example.com
Din SignalR app finns på http://signalr.example.com

CORS bör konfigureras i SignalR appen för att endast tillåta ursprunget www.example.com.

Mer information om hur du konfigurerar CORS finns i Aktivera CORS (Cross-Origin Requests). SignalR kräver följande CORS-principer:

Tillåt de specifika förväntade källorna. Att tillåta alla ursprung är möjligt, men det är inte säkert eller rekommenderat.
HTTP-metoder GET och POST måste tillåtas.
Autentiseringsuppgifter måste tillåtas för att cookie-baserade persistenta sessioner ska fungera korrekt. De måste vara aktiverade även när autentisering inte används.

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");

Begränsning av WebSocket-ursprung

De skydd som tillhandahålls av CORS gäller inte för WebSockets. För ursprungsbegränsning på WebSockets läser du Ursprungsbegränsning för WebSockets.

ConnectionId

Loggning av åtkomsttoken

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

Undantag

Bufferthantering

Förhindrar att en klient kan skicka ett större meddelande.
Servern behöver aldrig allokera stora buffertar för att acceptera meddelanden.

Om dina meddelanden är större än 32 KB kan du öka gränsen. Om du ökar den här gränsen innebär det att:

Klienten kan göra så att servern allokerar stora minnesbuffertar.
Serverallokering av stora buffertar kan minska antalet samtidiga anslutningar.

Det finns gränser för inkommande och utgående meddelanden, båda kan konfigureras för objektet HttpConnectionDispatcherOptions som konfigurerats i MapHub:

ApplicationMaxBufferSize representerar det maximala antalet byte från klienten som servern buffrar. Om klienten försöker skicka ett meddelande som är större än den här gränsen kan anslutningen stängas.
TransportMaxBufferSize representerar det maximala antalet byte som servern kan skicka. Om servern försöker skicka ett meddelande (inklusive returvärden från hubbmetoder) som är större än den här gränsen utlöses ett undantag.

Den här artikeln innehåller information om hur du SignalRskyddar .

Webbplatsen finns på http://www.example.com
Din SignalR app finns på http://signalr.example.com

CORS bör konfigureras i SignalR appen för att endast tillåta ursprunget www.example.com.

Mer information om hur du konfigurerar CORS finns i Aktivera CORS (Cross-Origin Requests). SignalR kräver följande CORS-principer:

Tillåt de specifika förväntade källorna. Att tillåta alla ursprung är möjligt, men det är inte säkert eller rekommenderat.
HTTP-metoder GET och POST måste tillåtas.
Autentiseringsuppgifter måste tillåtas för att cookie-baserade persistenta sessioner ska fungera korrekt. De måste vara aktiverade även när autentisering inte används.

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");

Begränsning av WebSocket-ursprung

De skydd som tillhandahålls av CORS gäller inte för WebSockets. För ursprungsbegränsning på WebSockets läser du Ursprungsbegränsning för WebSockets.

ConnectionId

Loggning av åtkomsttoken

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

Undantag

Bufferthantering

Förhindrar att en klient kan skicka ett större meddelande.
Servern behöver aldrig allokera stora buffertar för att acceptera meddelanden.

Om dina meddelanden är större än 32 KB kan du öka gränsen. Om du ökar den här gränsen innebär det att:

Klienten kan göra så att servern allokerar stora minnesbuffertar.
Serverallokering av stora buffertar kan minska antalet samtidiga anslutningar.

Det finns gränser för inkommande och utgående meddelanden, båda kan konfigureras för objektet HttpConnectionDispatcherOptions som konfigurerats i MapHub:

ApplicationMaxBufferSize representerar det maximala antalet byte från klienten som servern buffrar. Om klienten försöker skicka ett meddelande som är större än den här gränsen kan anslutningen stängas.
TransportMaxBufferSize representerar det maximala antalet byte som servern kan skicka. Om servern försöker skicka ett meddelande (inklusive returvärden från hubbmetoder) som är större än den här gränsen utlöses ett undantag.

Den här artikeln innehåller information om hur du SignalRskyddar .

Webbplatsen finns på http://www.example.com
Din SignalR app finns på http://signalr.example.com

CORS bör konfigureras i SignalR appen för att endast tillåta ursprunget www.example.com.

Mer information om hur du konfigurerar CORS finns i Aktivera CORS (Cross-Origin Requests). SignalR kräver följande CORS-principer:

Tillåt de specifika förväntade källorna. Att tillåta alla ursprung är möjligt, men det är inte säkert eller rekommenderat.
HTTP-metoder GET och POST måste tillåtas.
Autentiseringsuppgifter måste tillåtas för att cookie-baserade persistenta sessioner ska fungera korrekt. De måste vara aktiverade även när autentisering inte används.

Följande CORS-princip tillåter till exempel att en SignalR webbläsarklient som finns på https://example.com får åtkomst till appen som SignalR finns på 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 ...
}

Begränsning av WebSocket-ursprung

De skydd som tillhandahålls av CORS gäller inte för WebSockets. För ursprungsbegränsning på WebSockets läser du Ursprungsbegränsning för WebSockets.

De skydd som tillhandahålls av CORS gäller inte för WebSockets. Webbläsare gör inte:

Utför CORS-begäranden före flygning.
Respektera de begränsningar som anges i Access-Control rubriker när du gör WebSocket-begäranden.

Webbläsare skickar dock Origin-huvudet när de utfärdar WebSocket-begäranden. Program bör konfigureras för att verifiera dessa huvuden för att säkerställa att endast WebSockets som kommer från det förväntade ursprunget tillåts.

I ASP.NET Core 2.1 eller senare kan sidhuvudverifiering uppnås med hjälp av ett anpassat mellanprogram som placerats före UseSignalRoch autentiseringsmellanprogram i 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 ...
}

Anmärkning

Origin-huvudet styrs av klienten och, precis som Referer-huvudet, kan förfalskas. Dessa huvuden bör inte användas som en autentiseringsmekanism.

ConnectionId

Loggning av åtkomsttoken

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

Undantag

Bufferthantering

Förhindrar att en klient kan skicka ett större meddelande.
Servern behöver aldrig allokera stora buffertar för att acceptera meddelanden.

Om dina meddelanden är större än 32 KB kan du öka gränsen. Om du ökar den här gränsen innebär det att:

Klienten kan göra så att servern allokerar stora minnesbuffertar.
Serverallokering av stora buffertar kan minska antalet samtidiga anslutningar.

Det finns gränser för inkommande och utgående meddelanden, båda kan konfigureras för objektet HttpConnectionDispatcherOptions som konfigurerats i MapHub:

ApplicationMaxBufferSize representerar det maximala antalet byte från klienten som servern buffrar. Om klienten försöker skicka ett meddelande som är större än den här gränsen kan anslutningen stängas.
TransportMaxBufferSize representerar det maximala antalet byte som servern kan skicka. Om servern försöker skicka ett meddelande (inklusive returvärden från hubbmetoder) som är större än den här gränsen utlöses ett undantag.

Feedback

Var den här sidan till hjälp?

Dela via

Säkerhetsöverväganden i ASP.NET Core SignalR

Delning av resurser över ursprung

Begränsning av WebSocket-ursprung

ConnectionId

Loggning av åtkomsttoken

Undantag

Bufferthantering

Delning av resurser över ursprung

Begränsning av WebSocket-ursprung

ConnectionId

Loggning av åtkomsttoken

Undantag

Bufferthantering

Delning av resurser över ursprung

Begränsning av WebSocket-ursprung

ConnectionId

Loggning av åtkomsttoken

Undantag

Bufferthantering

Delning av resurser över ursprung

Begränsning av WebSocket-ursprung

ConnectionId

Loggning av åtkomsttoken

Undantag

Bufferthantering

Feedback

Ytterligare resurser