Aspekty zabezpečení v ASP.NET Core SignalR

Andrew Stanton-Nurse

Tento článek obsahuje informace o zabezpečení SignalR.

Sdílení prostředků mezi zdroji

Sdílení prostředků mezi zdroji (CORS) se dá použít k povolení připojení mezi zdroji SignalR v prohlížeči. Pokud je javascriptový kód hostovaný v jiné doméně než SignalR aplikace, musí být povolený middleware CORS, aby se javascript mohl k aplikaci připojitSignalR. Povolte žádosti mezi zdroji pouze z domén, kterým důvěřujete nebo řídíte. Příklad:

  • Váš web je hostovaný na http://www.example.com
  • Vaše SignalR aplikace je hostovaná na http://signalr.example.com

CORS by měl být v SignalR aplikaci nakonfigurovaný tak, aby povoloval pouze zdroj www.example.com.

Další informace o konfiguraci CORS najdete v tématu Povolení žádostí mezi zdroji (CORS). SignalRvyžaduje následující zásady CORS:

  • Povolte konkrétní očekávané původy. Povolení jakéhokoli původu je možné, ale není bezpečné nebo doporučené.
  • Metody GET HTTP a POST musí být povolené.
  • Přihlašovací údaje musí být povolené, aby cookierychlé relace založené na relacích fungovaly správně. Musí být povolené i v případě, že se ověřování nepoužívá.

Ve verzi 5.0 jsme ale v klientovi TypeScriptu poskytli možnost nepoužívat přihlašovací údaje. Možnost nepoužívat přihlašovací údaje by se měla používat jenom v případě, že znáte 100 % přihlašovacích údajů, jako Cookiejsou s, nejsou ve vaší aplikaci potřeba (cookies se používají službou Azure App Service při použití více serverů pro rychlé relace).

Například následující zvýrazněná zásada CORS umožňuje SignalR klientovi prohlížeče hostovanýmu https://example.com v aplikaci přístup k SignalR aplikaci hostované na 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");

V předchozím příkladu je zásada CORS přizpůsobená tak, aby umožňovala konkrétní původy, metody a přihlašovací údaje. Další informace o přizpůsobení zásad CORS a middlewaru v ASP.NET Core najdete v middlewaru CORS: CORS s pojmenovanými zásadami a middlewarem.

Omezení původu protokolu WebSocket

Ochrana poskytovaná CORS se nevztahuje na webSockety. V případě omezení původu u webSocket si přečtěte omezení původu webSocket.

ConnectionId

Zveřejnění ConnectionId může vést ke zosobnění se zlými úmysly, pokud SignalR je server nebo verze klienta ASP.NET Core 2.2 nebo starší. SignalR Pokud je verze serveru a klienta ASP.NET Core 3.0 nebo novější, je nutné, ConnectionToken aby se místo uchovávání tajného ConnectionId kódu zachovalo. Účelně ConnectionToken se nezpřístupní v žádném rozhraní API. Může být obtížné zajistit, že se starší SignalR klienti nepřipojují k serveru, takže i když je vaše SignalR verze serveru ASP.NET Core 3.0 nebo novější, ConnectionId nemělo by se vystavit.

Protokolování přístupového tokenu

Při použití protokolu WebSocket nebo Server-Sent Events odešle klient prohlížeče přístupový token v řetězci dotazu. Příjem přístupového tokenu prostřednictvím řetězce dotazu je obecně stejně bezpečný jako použití standardní Authorization hlavičky. Vždy používejte protokol HTTPS k zajištění zabezpečeného kompletního připojení mezi klientem a serverem. Mnoho webových serverů protokoluje adresu URL pro každý požadavek, včetně řetězce dotazu. Protokolování adres URL může protokolovat přístupový token. ASP.NET Core protokoluje adresu URL pro každý požadavek ve výchozím nastavení, což zahrnuje řetězec dotazu. Příklad:

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

Pokud máte obavy o protokolování těchto dat pomocí protokolů serveru, můžete toto protokolování úplně zakázat konfigurací Microsoft.AspNetCore.Hosting protokolovacího nástroje na Warning úroveň nebo vyšší (tyto zprávy se zapisují na Info úrovni). Další informace naleznete v tématu Použití pravidel filtru protokolu v kódu další informace. Pokud stále chcete protokolovat určité informace o požadavku, můžete do middlewaruaccess_token zapsat data, která požadujete, a vyfiltrovat hodnotu řetězce dotazu (pokud je k dispozici).

Výjimky

Zprávy o výjimce se obecně považují za citlivá data, která by neměla být klientovi odhalena. Ve výchozím nastavení SignalR neodesílá klientovi podrobnosti o výjimce vyvolané metodou centra. Místo toho se klientovi zobrazí obecná zpráva oznamující, že došlo k chybě. Doručení zprávy o výjimce klientovi je možné přepsat (například ve vývoji nebo testu) pomocí enableDetailedErrors. Zprávy o výjimce by neměly být klientovi vystaveny v produkčních aplikacích.

Správa vyrovnávací paměti

SignalR používá vyrovnávací paměti pro připojení ke správě příchozích a odchozích zpráv. Ve výchozím nastavení SignalR tyto vyrovnávací paměti omezuje na 32 kB. Největší zpráva, kterou klient nebo server může odeslat, je 32 kB. Maximální paměť spotřebovaná připojením pro zprávy je 32 kB. Pokud jsou vaše zprávy vždy menší než 32 kB, můžete limit snížit, což:

  • Zabrání klientovi v odesílání větší zprávy.
  • Server nikdy nebude muset přidělovat velké vyrovnávací paměti pro příjem zpráv.

Pokud jsou vaše zprávy větší než 32 kB, můžete limit zvýšit. Zvýšení tohoto limitu znamená:

  • Klient může způsobit, že server přidělí velké vyrovnávací paměti.
  • Přidělení velkých vyrovnávacích pamětí může snížit počet souběžných připojení.

Pro příchozí a odchozí zprávy platí omezení, obě je možné nakonfigurovat na objektu Http Připojení ionDispatcherOptions nakonfigurovaný vMapHub:

  • ApplicationMaxBufferSize představuje maximální počet bajtů z klienta, který server vyrovnávací paměti. Pokud se klient pokusí odeslat zprávu větší než tento limit, může být připojení uzavřeno.
  • TransportMaxBufferSize představuje maximální počet bajtů, které může server odeslat. Pokud se server pokusí odeslat zprávu (včetně návratových hodnot z metod centra) větší než tento limit, vyvolá se výjimka.

Nastavením limitu limit 0 zakážete. Odebrání limitu umožňuje klientovi odeslat zprávu o libovolné velikosti. Škodlivé klienty, kteří odesílají velké zprávy, můžou způsobit přidělení nadbytečné paměti. Nadbytečné využití paměti může výrazně snížit počet souběžných připojení.

Tento článek obsahuje informace o zabezpečení SignalR.

Sdílení prostředků mezi zdroji

Sdílení prostředků mezi zdroji (CORS) se dá použít k povolení připojení mezi zdroji SignalR v prohlížeči. Pokud je javascriptový kód hostovaný v jiné doméně než SignalR aplikace, musí být povolený middleware CORS, aby se javascript mohl k aplikaci připojitSignalR. Povolte žádosti mezi zdroji pouze z domén, kterým důvěřujete nebo řídíte. Příklad:

  • Váš web je hostovaný na http://www.example.com
  • Vaše SignalR aplikace je hostovaná na http://signalr.example.com

CORS by měl být v SignalR aplikaci nakonfigurovaný tak, aby povoloval pouze zdroj www.example.com.

Další informace o konfiguraci CORS najdete v tématu Povolení žádostí mezi zdroji (CORS). SignalRvyžaduje následující zásady CORS:

  • Povolte konkrétní očekávané původy. Povolení jakéhokoli původu je možné, ale není bezpečné nebo doporučené.
  • Metody GET HTTP a POST musí být povolené.
  • Přihlašovací údaje musí být povolené, aby cookierychlé relace založené na relacích fungovaly správně. Musí být povolené i v případě, že se ověřování nepoužívá.

Ve verzi 5.0 jsme ale v klientovi TypeScriptu poskytli možnost nepoužívat přihlašovací údaje. Možnost nepoužívat přihlašovací údaje by se měla používat jenom v případě, že znáte 100 % přihlašovacích údajů, jako Cookiejsou s, nejsou ve vaší aplikaci potřeba (cookies se používají službou Azure App Service při použití více serverů pro rychlé relace).

Například následující zvýrazněná zásada CORS umožňuje SignalR klientovi prohlížeče hostovanýmu https://example.com v aplikaci přístup k SignalR aplikaci hostované na 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");

V předchozím příkladu je zásada CORS přizpůsobená tak, aby umožňovala konkrétní původy, metody a přihlašovací údaje. Další informace o přizpůsobení zásad CORS a middlewaru v ASP.NET Core najdete v middlewaru CORS: CORS s pojmenovanými zásadami a middlewarem.

Omezení původu protokolu WebSocket

Ochrana poskytovaná CORS se nevztahuje na webSockety. V případě omezení původu u webSocket si přečtěte omezení původu webSocket.

ConnectionId

Zveřejnění ConnectionId může vést ke zosobnění se zlými úmysly, pokud SignalR je server nebo verze klienta ASP.NET Core 2.2 nebo starší. SignalR Pokud je verze serveru a klienta ASP.NET Core 3.0 nebo novější, je nutné, ConnectionToken aby se místo uchovávání tajného ConnectionId kódu zachovalo. Účelně ConnectionToken se nezpřístupní v žádném rozhraní API. Může být obtížné zajistit, že se starší SignalR klienti nepřipojují k serveru, takže i když je vaše SignalR verze serveru ASP.NET Core 3.0 nebo novější, ConnectionId nemělo by se vystavit.

Protokolování přístupového tokenu

Při použití protokolu WebSocket nebo Server-Sent Events odešle klient prohlížeče přístupový token v řetězci dotazu. Příjem přístupového tokenu prostřednictvím řetězce dotazu je obecně stejně bezpečný jako použití standardní Authorization hlavičky. Vždy používejte protokol HTTPS k zajištění zabezpečeného kompletního připojení mezi klientem a serverem. Mnoho webových serverů protokoluje adresu URL pro každý požadavek, včetně řetězce dotazu. Protokolování adres URL může protokolovat přístupový token. ASP.NET Core protokoluje adresu URL pro každý požadavek ve výchozím nastavení, což zahrnuje řetězec dotazu. Příklad:

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

Pokud máte obavy o protokolování těchto dat pomocí protokolů serveru, můžete toto protokolování úplně zakázat konfigurací Microsoft.AspNetCore.Hosting protokolovacího nástroje na Warning úroveň nebo vyšší (tyto zprávy se zapisují na Info úrovni). Další informace naleznete v tématu Použití pravidel filtru protokolu v kódu další informace. Pokud stále chcete protokolovat určité informace o požadavku, můžete do middlewaruaccess_token zapsat data, která požadujete, a vyfiltrovat hodnotu řetězce dotazu (pokud je k dispozici).

Výjimky

Zprávy o výjimce se obecně považují za citlivá data, která by neměla být klientovi odhalena. Ve výchozím nastavení SignalR neodesílá klientovi podrobnosti o výjimce vyvolané metodou centra. Místo toho se klientovi zobrazí obecná zpráva oznamující, že došlo k chybě. Doručení zprávy o výjimce klientovi je možné přepsat (například ve vývoji nebo testu) pomocí enableDetailedErrors. Zprávy o výjimce by neměly být klientovi vystaveny v produkčních aplikacích.

Správa vyrovnávací paměti

SignalR používá vyrovnávací paměti pro připojení ke správě příchozích a odchozích zpráv. Ve výchozím nastavení SignalR tyto vyrovnávací paměti omezuje na 32 kB. Největší zpráva, kterou klient nebo server může odeslat, je 32 kB. Maximální paměť spotřebovaná připojením pro zprávy je 32 kB. Pokud jsou vaše zprávy vždy menší než 32 kB, můžete limit snížit, což:

  • Zabrání klientovi v odesílání větší zprávy.
  • Server nikdy nebude muset přidělovat velké vyrovnávací paměti pro příjem zpráv.

Pokud jsou vaše zprávy větší než 32 kB, můžete limit zvýšit. Zvýšení tohoto limitu znamená:

  • Klient může způsobit, že server přidělí velké vyrovnávací paměti.
  • Přidělení velkých vyrovnávacích pamětí může snížit počet souběžných připojení.

Pro příchozí a odchozí zprávy platí omezení, obě je možné nakonfigurovat na objektu Http Připojení ionDispatcherOptions nakonfigurovaný vMapHub:

  • ApplicationMaxBufferSize představuje maximální počet bajtů z klienta, který server vyrovnávací paměti. Pokud se klient pokusí odeslat zprávu větší než tento limit, může být připojení uzavřeno.
  • TransportMaxBufferSize představuje maximální počet bajtů, které může server odeslat. Pokud se server pokusí odeslat zprávu (včetně návratových hodnot z metod centra) větší než tento limit, vyvolá se výjimka.

Nastavením limitu limit 0 zakážete. Odebrání limitu umožňuje klientovi odeslat zprávu o libovolné velikosti. Škodlivé klienty, kteří odesílají velké zprávy, můžou způsobit přidělení nadbytečné paměti. Nadbytečné využití paměti může výrazně snížit počet souběžných připojení.

Tento článek obsahuje informace o zabezpečení SignalR.

Sdílení prostředků mezi zdroji

Sdílení prostředků mezi zdroji (CORS) se dá použít k povolení připojení mezi zdroji SignalR v prohlížeči. Pokud je javascriptový kód hostovaný v jiné doméně než SignalR aplikace, musí být povolený middleware CORS, aby se javascript mohl k aplikaci připojitSignalR. Povolte žádosti mezi zdroji pouze z domén, kterým důvěřujete nebo řídíte. Příklad:

  • Váš web je hostovaný na http://www.example.com
  • Vaše SignalR aplikace je hostovaná na http://signalr.example.com

CORS by měl být v SignalR aplikaci nakonfigurovaný tak, aby povoloval pouze zdroj www.example.com.

Další informace o konfiguraci CORS najdete v tématu Povolení žádostí mezi zdroji (CORS). SignalRvyžaduje následující zásady CORS:

  • Povolte konkrétní očekávané původy. Povolení jakéhokoli původu je možné, ale není bezpečné nebo doporučené.
  • Metody GET HTTP a POST musí být povolené.
  • Přihlašovací údaje musí být povolené, aby cookierychlé relace založené na relacích fungovaly správně. Musí být povolené i v případě, že se ověřování nepoužívá.

Ve verzi 5.0 jsme ale v klientovi TypeScriptu poskytli možnost nepoužívat přihlašovací údaje. Možnost nepoužívat přihlašovací údaje by se měla používat jenom v případě, že znáte 100 % přihlašovacích údajů, jako Cookiejsou s, nejsou ve vaší aplikaci potřeba (cookies se používají službou Azure App Service při použití více serverů pro rychlé relace).

Například následující zvýrazněná zásada CORS umožňuje SignalR klientovi prohlížeče hostovanýmu https://example.com v aplikaci přístup k SignalR aplikaci hostované na 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");

V předchozím příkladu je zásada CORS přizpůsobená tak, aby umožňovala konkrétní původy, metody a přihlašovací údaje. Další informace o přizpůsobení zásad CORS a middlewaru v ASP.NET Core najdete v middlewaru CORS: CORS s pojmenovanými zásadami a middlewarem.

Omezení původu protokolu WebSocket

Ochrana poskytovaná CORS se nevztahuje na webSockety. V případě omezení původu u webSocket si přečtěte omezení původu webSocket.

ConnectionId

Zveřejnění ConnectionId může vést ke zosobnění se zlými úmysly, pokud SignalR je server nebo verze klienta ASP.NET Core 2.2 nebo starší. SignalR Pokud je verze serveru a klienta ASP.NET Core 3.0 nebo novější, je nutné, ConnectionToken aby se místo uchovávání tajného ConnectionId kódu zachovalo. Účelně ConnectionToken se nezpřístupní v žádném rozhraní API. Může být obtížné zajistit, že se starší SignalR klienti nepřipojují k serveru, takže i když je vaše SignalR verze serveru ASP.NET Core 3.0 nebo novější, ConnectionId nemělo by se vystavit.

Protokolování přístupového tokenu

Při použití protokolu WebSocket nebo Server-Sent Events odešle klient prohlížeče přístupový token v řetězci dotazu. Příjem přístupového tokenu prostřednictvím řetězce dotazu je obecně stejně bezpečný jako použití standardní Authorization hlavičky. Vždy používejte protokol HTTPS k zajištění zabezpečeného kompletního připojení mezi klientem a serverem. Mnoho webových serverů protokoluje adresu URL pro každý požadavek, včetně řetězce dotazu. Protokolování adres URL může protokolovat přístupový token. ASP.NET Core protokoluje adresu URL pro každý požadavek ve výchozím nastavení, což zahrnuje řetězec dotazu. Příklad:

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

Pokud máte obavy o protokolování těchto dat pomocí protokolů serveru, můžete toto protokolování úplně zakázat konfigurací Microsoft.AspNetCore.Hosting protokolovacího nástroje na Warning úroveň nebo vyšší (tyto zprávy se zapisují na Info úrovni). Další informace naleznete v tématu Použití pravidel filtru protokolu v kódu další informace. Pokud stále chcete protokolovat určité informace o požadavku, můžete do middlewaruaccess_token zapsat data, která požadujete, a vyfiltrovat hodnotu řetězce dotazu (pokud je k dispozici).

Výjimky

Zprávy o výjimce se obecně považují za citlivá data, která by neměla být klientovi odhalena. Ve výchozím nastavení SignalR neodesílá klientovi podrobnosti o výjimce vyvolané metodou centra. Místo toho se klientovi zobrazí obecná zpráva oznamující, že došlo k chybě. Doručení zprávy o výjimce klientovi je možné přepsat (například ve vývoji nebo testu) pomocí enableDetailedErrors. Zprávy o výjimce by neměly být klientovi vystaveny v produkčních aplikacích.

Správa vyrovnávací paměti

SignalR používá vyrovnávací paměti pro připojení ke správě příchozích a odchozích zpráv. Ve výchozím nastavení SignalR tyto vyrovnávací paměti omezuje na 32 kB. Největší zpráva, kterou klient nebo server může odeslat, je 32 kB. Maximální paměť spotřebovaná připojením pro zprávy je 32 kB. Pokud jsou vaše zprávy vždy menší než 32 kB, můžete limit snížit, což:

  • Zabrání klientovi v odesílání větší zprávy.
  • Server nikdy nebude muset přidělovat velké vyrovnávací paměti pro příjem zpráv.

Pokud jsou vaše zprávy větší než 32 kB, můžete limit zvýšit. Zvýšení tohoto limitu znamená:

  • Klient může způsobit, že server přidělí velké vyrovnávací paměti.
  • Přidělení velkých vyrovnávacích pamětí může snížit počet souběžných připojení.

Pro příchozí a odchozí zprávy platí omezení, obě je možné nakonfigurovat na objektu Http Připojení ionDispatcherOptions nakonfigurovaný vMapHub:

  • ApplicationMaxBufferSize představuje maximální počet bajtů z klienta, který server vyrovnávací paměti. Pokud se klient pokusí odeslat zprávu větší než tento limit, může být připojení uzavřeno.
  • TransportMaxBufferSize představuje maximální počet bajtů, které může server odeslat. Pokud se server pokusí odeslat zprávu (včetně návratových hodnot z metod centra) větší než tento limit, vyvolá se výjimka.

Nastavením limitu limit 0 zakážete. Odebrání limitu umožňuje klientovi odeslat zprávu o libovolné velikosti. Škodlivé klienty, kteří odesílají velké zprávy, můžou způsobit přidělení nadbytečné paměti. Nadbytečné využití paměti může výrazně snížit počet souběžných připojení.

Tento článek obsahuje informace o zabezpečení SignalR.

Sdílení prostředků mezi zdroji

Sdílení prostředků mezi zdroji (CORS) se dá použít k povolení připojení mezi zdroji SignalR v prohlížeči. Pokud je javascriptový kód hostovaný v jiné doméně než SignalR aplikace, musí být povolený middleware CORS, aby se javascript mohl k aplikaci připojitSignalR. Povolte žádosti mezi zdroji pouze z domén, kterým důvěřujete nebo řídíte. Příklad:

  • Váš web je hostovaný na http://www.example.com
  • Vaše SignalR aplikace je hostovaná na http://signalr.example.com

CORS by měl být v SignalR aplikaci nakonfigurovaný tak, aby povoloval pouze zdroj www.example.com.

Další informace o konfiguraci CORS najdete v tématu Povolení žádostí mezi zdroji (CORS). SignalRvyžaduje následující zásady CORS:

  • Povolte konkrétní očekávané původy. Povolení jakéhokoli původu je možné, ale není bezpečné nebo doporučené.
  • Metody GET HTTP a POST musí být povolené.
  • Přihlašovací údaje musí být povolené, aby cookierychlé relace založené na relacích fungovaly správně. Musí být povolené i v případě, že se ověřování nepoužívá.

Ve verzi 5.0 jsme ale v klientovi TypeScriptu poskytli možnost nepoužívat přihlašovací údaje. Možnost nepoužívat přihlašovací údaje by se měla používat jenom v případě, že znáte 100 % přihlašovacích údajů, jako Cookiejsou s, nejsou ve vaší aplikaci potřeba (cookies se používají službou Azure App Service při použití více serverů pro rychlé relace).

Například následující zásady CORS umožňují SignalR klientovi prohlížeče hostovaným přístup k SignalR aplikaci hostované https://example.com nahttps://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 ...
}

Omezení původu protokolu WebSocket

Ochrana poskytovaná CORS se nevztahuje na webSockety. V případě omezení původu u webSocket si přečtěte omezení původu webSocket.

Ochrana poskytovaná CORS se nevztahuje na webSockety. Prohlížeče:

  • Proveďte předběžné žádosti CORS.
  • Při vytváření požadavků WebSocket respektujte omezení zadaná v Access-Control hlavicích.

Prohlížeče však posílají hlavičku Origin při vydávání požadavků WebSocket. Aplikace by měly být nakonfigurované tak, aby ověřily tyto hlavičky, aby se zajistilo, že jsou povoleny pouze protokoly WebSocket pocházející z očekávaných zdrojů.

V ASP.NET Core 2.1 a novějším lze ověření hlaviček dosáhnout pomocí vlastního middlewaru umístěného před UseSignalRa ověřovacího middlewaru v 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 ...
}

Poznámka:

Hlavička Origin je řízena klientem a podobně jako hlavička Referer může být falešně napodobena. Tyto hlavičky by se neměly používat jako ověřovací mechanismus.

ConnectionId

Zveřejnění ConnectionId může vést ke zosobnění se zlými úmysly, pokud SignalR je server nebo verze klienta ASP.NET Core 2.2 nebo starší. SignalR Pokud je verze serveru a klienta ASP.NET Core 3.0 nebo novější, je nutné, ConnectionToken aby se místo uchovávání tajného ConnectionId kódu zachovalo. Účelně ConnectionToken se nezpřístupní v žádném rozhraní API. Může být obtížné zajistit, že se starší SignalR klienti nepřipojují k serveru, takže i když je vaše SignalR verze serveru ASP.NET Core 3.0 nebo novější, ConnectionId nemělo by se vystavit.

Protokolování přístupového tokenu

Při použití protokolu WebSocket nebo Server-Sent Events odešle klient prohlížeče přístupový token v řetězci dotazu. Příjem přístupového tokenu prostřednictvím řetězce dotazu je obecně stejně bezpečný jako použití standardní Authorization hlavičky. Vždy používejte protokol HTTPS k zajištění zabezpečeného kompletního připojení mezi klientem a serverem. Mnoho webových serverů protokoluje adresu URL pro každý požadavek, včetně řetězce dotazu. Protokolování adres URL může protokolovat přístupový token. ASP.NET Core protokoluje adresu URL pro každý požadavek ve výchozím nastavení, což zahrnuje řetězec dotazu. Příklad:

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

Pokud máte obavy o protokolování těchto dat pomocí protokolů serveru, můžete toto protokolování úplně zakázat konfigurací Microsoft.AspNetCore.Hosting protokolovacího nástroje na Warning úroveň nebo vyšší (tyto zprávy se zapisují na Info úrovni). Další informace naleznete v tématu Použití pravidel filtru protokolu v kódu další informace. Pokud stále chcete protokolovat určité informace o požadavku, můžete do middlewaruaccess_token zapsat data, která požadujete, a vyfiltrovat hodnotu řetězce dotazu (pokud je k dispozici).

Výjimky

Zprávy o výjimce se obecně považují za citlivá data, která by neměla být klientovi odhalena. Ve výchozím nastavení SignalR neodesílá klientovi podrobnosti o výjimce vyvolané metodou centra. Místo toho se klientovi zobrazí obecná zpráva oznamující, že došlo k chybě. Doručení zprávy o výjimce klientovi je možné přepsat (například ve vývoji nebo testu) pomocí enableDetailedErrors. Zprávy o výjimce by neměly být klientovi vystaveny v produkčních aplikacích.

Správa vyrovnávací paměti

SignalR používá vyrovnávací paměti pro připojení ke správě příchozích a odchozích zpráv. Ve výchozím nastavení SignalR tyto vyrovnávací paměti omezuje na 32 kB. Největší zpráva, kterou klient nebo server může odeslat, je 32 kB. Maximální paměť spotřebovaná připojením pro zprávy je 32 kB. Pokud jsou vaše zprávy vždy menší než 32 kB, můžete limit snížit, což:

  • Zabrání klientovi v odesílání větší zprávy.
  • Server nikdy nebude muset přidělovat velké vyrovnávací paměti pro příjem zpráv.

Pokud jsou vaše zprávy větší než 32 kB, můžete limit zvýšit. Zvýšení tohoto limitu znamená:

  • Klient může způsobit, že server přidělí velké vyrovnávací paměti.
  • Přidělení velkých vyrovnávacích pamětí může snížit počet souběžných připojení.

Pro příchozí a odchozí zprávy platí omezení, obě je možné nakonfigurovat na objektu Http Připojení ionDispatcherOptions nakonfigurovaný vMapHub:

  • ApplicationMaxBufferSize představuje maximální počet bajtů z klienta, který server vyrovnávací paměti. Pokud se klient pokusí odeslat zprávu větší než tento limit, může být připojení uzavřeno.
  • TransportMaxBufferSize představuje maximální počet bajtů, které může server odeslat. Pokud se server pokusí odeslat zprávu (včetně návratových hodnot z metod centra) větší než tento limit, vyvolá se výjimka.

Nastavením limitu limit 0 zakážete. Odebrání limitu umožňuje klientovi odeslat zprávu o libovolné velikosti. Škodlivé klienty, kteří odesílají velké zprávy, můžou způsobit přidělení nadbytečné paměti. Nadbytečné využití paměti může výrazně snížit počet souběžných připojení.