Beveiligingsoverwegingen in ASP.NET Core SignalR

2025-05-05

In dit artikel vindt u informatie over beveiliging SignalR.

CorS (Cross-Origin Resource Sharing) kan worden gebruikt om cross-origin-verbindingen SignalR in de browser toe te staan. Als JavaScript-code wordt gehost in een ander domein dan de SignalR app, moet CORS-middleware zijn ingeschakeld zodat JavaScript verbinding kan maken met de SignalR app. Sta alleen cross-origin aanvragen toe van domeinen die u vertrouwt of controleert. Voorbeeld:

Uw site wordt gehost op http://www.example.com
Uw SignalR app wordt gehost op http://signalr.example.com

CORS moet worden geconfigureerd in de SignalR app om alleen de oorsprong www.example.com toe te staan.

Zie CORS (Cross-Origin Requests) inschakelen voor meer informatie over het configureren van CORS. SignalR vereist het volgende CORS-beleid:

Sta de specifieke verwachte herkomst toe. Het toestaan van een oorsprong is mogelijk, maar is niet veilig of aanbevolen.
HTTP-methoden GET en POST moeten zijn toegestaan.
Inloggegevens moeten worden toegestaan om op cookie gebaseerde plaksessies correct te laten werken. Ze moeten worden ingeschakeld, zelfs wanneer verificatie niet wordt gebruikt.

In 5.0 hebben we echter een optie opgegeven in de TypeScript-client om geen referenties te gebruiken. De optie om geen referenties te gebruiken, mag alleen worden gebruikt wanneer u 100% weet dat referenties zoals Cookies niet nodig zijn in uw app (cookies worden gebruikt door Azure App Service wanneer u meerdere servers gebruikt voor plaksessies).

Met het hierboven gemarkeerde CORS-beleid kan bijvoorbeeld een SignalR browserclient die op https://example.com wordt gehost, toegang krijgen tot de SignalR app die wordt gehost op 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");

In het vorige voorbeeld is het CORS-beleid aangepast om specifieke oorsprongen, methoden en referenties toe te staan. Zie CORS middleware: CORS met benoemd beleid en middleware voor meer informatie over het aanpassen van CORS-beleidsregels en middleware in ASP.NET Core.

Oorsprongsbeperking voor WebSocket

De beveiligingen van CORS zijn niet van toepassing op WebSockets. Lees oorsprongsbeperking voor WebSockets.

ConnectionId

ConnectionId Blootstelling kan leiden tot schadelijke imitatie als de SignalR server- of clientversie ASP.NET Core 2.2 of eerder is. Als de SignalR server- en clientversie ASP.NET Core 3.0 of hoger zijn, moet de ConnectionToken eerder dan de ConnectionId geheim worden gehouden. Het ConnectionToken is doelloos niet beschikbaar in een API. Het kan lastig zijn om ervoor te zorgen dat oudere SignalR clients geen verbinding maken met de server, dus zelfs als uw SignalR serverversie is ASP.NET Core 3.0 of hoger, mag deze ConnectionId niet worden weergegeven.

Logboekregistratie van toegangstokens

Wanneer u WebSockets of Server-Sent-gebeurtenissen gebruikt, verzendt de browserclient het toegangstoken in de querytekenreeks. Het ontvangen van het toegangstoken via een querytekenreeks is over het algemeen net zo veilig als het gebruik van de standaardheader Authorization . Gebruik ALTIJD HTTPS om een beveiligde end-to-end-verbinding tussen de client en de server te garanderen. Veel webservers registreren de URL voor elke aanvraag, inclusief de querytekenreeks. Het loggen van de URL's kan ertoe leiden dat het toegangstoken wordt vastgelegd. ASP.NET Core registreert standaard de URL voor elke aanvraag, die de querytekenreeks bevat. Voorbeeld:

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

Als u zich zorgen maakt over het vastleggen van deze gegevens met uw serverlogboeken, kunt u deze logboekregistratie volledig uitschakelen door de Microsoft.AspNetCore.Hosting logboekregistratie te configureren op het Warning niveau of hoger (deze berichten worden op Info niveau geschreven). Zie Logboekfilterregels toepassen in code voor meer informatie. Als u nog steeds bepaalde aanvraaggegevens wilt registreren, kunt u middleware schrijven om de gegevens die u nodig hebt te registreren en de waarde van de access_token querytekenreeks uit te filteren (indien aanwezig).

Uitzonderingen

Uitzonderingsberichten worden over het algemeen beschouwd als gevoelige gegevens die niet aan een client moeten worden onthuld. SignalR Standaard worden de details van een uitzondering die door een hubmethode wordt gegenereerd, niet naar de client verzonden. In plaats daarvan ontvangt de client een algemeen bericht dat aangeeft dat er een fout is opgetreden. De levering van uitzonderingsberichten naar de client kan worden overschreven (bijvoorbeeld tijdens ontwikkeling of testen) met EnableDetailedErrors. Uitzonderingsberichten mogen niet worden weergegeven voor de client in productie-apps.

Bufferbeheer

SignalR gebruikt buffers per verbinding om binnenkomende en uitgaande berichten te beheren. SignalR Standaard worden deze buffers beperkt tot 32 kB. Het grootste bericht dat een client of server kan verzenden, is 32 kB. Het maximale geheugen dat wordt verbruikt door een verbinding voor berichten is 32 kB. Als uw berichten altijd kleiner zijn dan 32 kB, kunt u de limiet beperken, wat:

Hiermee voorkomt u dat een client een groter bericht kan verzenden.
De server hoeft nooit grote buffers toe te wijzen om berichten te accepteren.

Als uw berichten groter zijn dan 32 kB, kunt u de limiet verhogen. Als u deze limiet verhoogt, betekent dit:

De client kan ertoe leiden dat de server grote geheugenbuffers toewijst.
Servertoewijzing van grote buffers kan het aantal gelijktijdige verbindingen verminderen.

Er zijn limieten voor binnenkomende en uitgaande berichten, beide kunnen worden geconfigureerd op het httpConnectionDispatcherOptions-object dat is geconfigureerd in MapHub:

ApplicationMaxBufferSize vertegenwoordigt het maximum aantal bytes van de client dat de server buffert. Als de client probeert een bericht te verzenden dat groter is dan deze limiet, kan de verbinding worden gesloten.
TransportMaxBufferSize vertegenwoordigt het maximum aantal bytes dat de server kan verzenden. Als de server probeert een bericht te verzenden (inclusief retourwaarden van hubmethoden) die groter zijn dan deze limiet, wordt er een uitzondering gegenereerd.

Als u de limiet instelt op 0, wordt de limiet uitgeschakeld. Door de limiet te verwijderen, kan een client een bericht van elke grootte verzenden. Kwaadwillende clients die grote berichten verzenden, kunnen ertoe leiden dat overtollig geheugen wordt toegewezen. Overtollig geheugengebruik kan het aantal gelijktijdige verbindingen aanzienlijk verminderen.

In dit artikel vindt u informatie over beveiliging SignalR.

Uw site wordt gehost op http://www.example.com
Uw SignalR app wordt gehost op http://signalr.example.com

CORS moet worden geconfigureerd in de SignalR app om alleen de oorsprong www.example.com toe te staan.

Zie CORS (Cross-Origin Requests) inschakelen voor meer informatie over het configureren van CORS. SignalR vereist het volgende CORS-beleid:

Sta de specifieke verwachte herkomst toe. Het toestaan van een oorsprong is mogelijk, maar is niet veilig of aanbevolen.
HTTP-methoden GET en POST moeten zijn toegestaan.
Inloggegevens moeten worden toegestaan om op cookie gebaseerde plaksessies correct te laten werken. Ze moeten worden ingeschakeld, zelfs wanneer verificatie niet wordt gebruikt.

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

Oorsprongsbeperking voor WebSocket

De beveiligingen van CORS zijn niet van toepassing op WebSockets. Lees oorsprongsbeperking voor WebSockets.

ConnectionId

Logboekregistratie van toegangstokens

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

Uitzonderingen

Bufferbeheer

Hiermee voorkomt u dat een client een groter bericht kan verzenden.
De server hoeft nooit grote buffers toe te wijzen om berichten te accepteren.

Als uw berichten groter zijn dan 32 kB, kunt u de limiet verhogen. Als u deze limiet verhoogt, betekent dit:

De client kan ertoe leiden dat de server grote geheugenbuffers toewijst.
Servertoewijzing van grote buffers kan het aantal gelijktijdige verbindingen verminderen.

Er zijn limieten voor binnenkomende en uitgaande berichten, beide kunnen worden geconfigureerd op het httpConnectionDispatcherOptions-object dat is geconfigureerd in MapHub:

ApplicationMaxBufferSize vertegenwoordigt het maximum aantal bytes van de client dat de server buffert. Als de client probeert een bericht te verzenden dat groter is dan deze limiet, kan de verbinding worden gesloten.
TransportMaxBufferSize vertegenwoordigt het maximum aantal bytes dat de server kan verzenden. Als de server probeert een bericht te verzenden (inclusief retourwaarden van hubmethoden) die groter zijn dan deze limiet, wordt er een uitzondering gegenereerd.

In dit artikel vindt u informatie over beveiliging SignalR.

Uw site wordt gehost op http://www.example.com
Uw SignalR app wordt gehost op http://signalr.example.com

CORS moet worden geconfigureerd in de SignalR app om alleen de oorsprong www.example.com toe te staan.

Zie CORS (Cross-Origin Requests) inschakelen voor meer informatie over het configureren van CORS. SignalR vereist het volgende CORS-beleid:

Sta de specifieke verwachte herkomst toe. Het toestaan van een oorsprong is mogelijk, maar is niet veilig of aanbevolen.
HTTP-methoden GET en POST moeten zijn toegestaan.
Inloggegevens moeten worden toegestaan om op cookie gebaseerde plaksessies correct te laten werken. Ze moeten worden ingeschakeld, zelfs wanneer verificatie niet wordt gebruikt.

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

Oorsprongsbeperking voor WebSocket

De beveiligingen van CORS zijn niet van toepassing op WebSockets. Lees oorsprongsbeperking voor WebSockets.

ConnectionId

Logboekregistratie van toegangstokens

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

Uitzonderingen

Bufferbeheer

Hiermee voorkomt u dat een client een groter bericht kan verzenden.
De server hoeft nooit grote buffers toe te wijzen om berichten te accepteren.

Als uw berichten groter zijn dan 32 kB, kunt u de limiet verhogen. Als u deze limiet verhoogt, betekent dit:

De client kan ertoe leiden dat de server grote geheugenbuffers toewijst.
Servertoewijzing van grote buffers kan het aantal gelijktijdige verbindingen verminderen.

Er zijn limieten voor binnenkomende en uitgaande berichten, beide kunnen worden geconfigureerd op het httpConnectionDispatcherOptions-object dat is geconfigureerd in MapHub:

ApplicationMaxBufferSize vertegenwoordigt het maximum aantal bytes van de client dat de server buffert. Als de client probeert een bericht te verzenden dat groter is dan deze limiet, kan de verbinding worden gesloten.
TransportMaxBufferSize vertegenwoordigt het maximum aantal bytes dat de server kan verzenden. Als de server probeert een bericht te verzenden (inclusief retourwaarden van hubmethoden) die groter zijn dan deze limiet, wordt er een uitzondering gegenereerd.

In dit artikel vindt u informatie over beveiliging SignalR.

Uw site wordt gehost op http://www.example.com
Uw SignalR app wordt gehost op http://signalr.example.com

CORS moet worden geconfigureerd in de SignalR app om alleen de oorsprong www.example.com toe te staan.

Zie CORS (Cross-Origin Requests) inschakelen voor meer informatie over het configureren van CORS. SignalR vereist het volgende CORS-beleid:

Sta de specifieke verwachte herkomst toe. Het toestaan van een oorsprong is mogelijk, maar is niet veilig of aanbevolen.
HTTP-methoden GET en POST moeten zijn toegestaan.
Inloggegevens moeten worden toegestaan om op cookie gebaseerde plaksessies correct te laten werken. Ze moeten worden ingeschakeld, zelfs wanneer verificatie niet wordt gebruikt.

Bijvoorbeeld: het volgende CORS-beleid biedt een SignalR browserclient die wordt gehost op https://example.com de mogelijkheid om toegang te krijgen tot de SignalR app die wordt gehost op 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 ...
}

Oorsprongsbeperking voor WebSocket

De beveiligingen van CORS zijn niet van toepassing op WebSockets. Lees oorsprongsbeperking voor WebSockets.

De beveiligingen van CORS zijn niet van toepassing op WebSockets. Browsers doen het volgende niet:

VOER CORS-aanvragen vooraf uit.
Respecteer de beperkingen die zijn opgegeven in Access-Control headers bij het maken van WebSocket-aanvragen.

Browsers verzenden echter wel de header bij het Origin uitgeven van WebSocket-aanvragen. Toepassingen moeten worden geconfigureerd om deze headers te valideren om ervoor te zorgen dat alleen WebSockets die afkomstig zijn van de verwachte oorsprongen zijn toegestaan.

In ASP.NET Core 2.1 of hoger kan headervalidatie worden bereikt met behulp van een aangepaste middleware die eerder UseSignalRis geplaatst en verificatie-middleware in 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 ...
}

Opmerking

De Origin header wordt beheerd door de client en kan, zoals de Referer header, worden vervalst. Deze headers mogen niet worden gebruikt als verificatiemechanisme.

ConnectionId

Logboekregistratie van toegangstokens

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

Uitzonderingen

Bufferbeheer

Hiermee voorkomt u dat een client een groter bericht kan verzenden.
De server hoeft nooit grote buffers toe te wijzen om berichten te accepteren.

Als uw berichten groter zijn dan 32 kB, kunt u de limiet verhogen. Als u deze limiet verhoogt, betekent dit:

De client kan ertoe leiden dat de server grote geheugenbuffers toewijst.
Servertoewijzing van grote buffers kan het aantal gelijktijdige verbindingen verminderen.

Er zijn limieten voor binnenkomende en uitgaande berichten, beide kunnen worden geconfigureerd op het httpConnectionDispatcherOptions-object dat is geconfigureerd in MapHub:

ApplicationMaxBufferSize vertegenwoordigt het maximum aantal bytes van de client dat de server buffert. Als de client probeert een bericht te verzenden dat groter is dan deze limiet, kan de verbinding worden gesloten.
TransportMaxBufferSize vertegenwoordigt het maximum aantal bytes dat de server kan verzenden. Als de server probeert een bericht te verzenden (inclusief retourwaarden van hubmethoden) die groter zijn dan deze limiet, wordt er een uitzondering gegenereerd.

Feedback

Is deze pagina nuttig?

Delen via

Beveiligingsoverwegingen in ASP.NET Core SignalR

Delen van bronnen tussen verschillende oorsprongen

Oorsprongsbeperking voor WebSocket

ConnectionId

Logboekregistratie van toegangstokens

Uitzonderingen

Bufferbeheer

Delen van bronnen tussen verschillende oorsprongen

Oorsprongsbeperking voor WebSocket

ConnectionId

Logboekregistratie van toegangstokens

Uitzonderingen

Bufferbeheer

Delen van bronnen tussen verschillende oorsprongen

Oorsprongsbeperking voor WebSocket

ConnectionId

Logboekregistratie van toegangstokens

Uitzonderingen

Bufferbeheer

Delen van bronnen tussen verschillende oorsprongen

Oorsprongsbeperking voor WebSocket

ConnectionId

Logboekregistratie van toegangstokens

Uitzonderingen

Bufferbeheer

Feedback

Aanvullende resources