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 aPOST
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 jsou soubory cookie, nejsou ve vaší aplikaci potřeba (soubory cookie používá služba 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 middlewaru access_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í.
Existují omezení pro příchozí a odchozí zprávy, obě je možné nakonfigurovat u objektu HttpConnectionDispatcherOptions nakonfigurovaného v MapHub
:
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 aPOST
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 jsou soubory cookie, nejsou ve vaší aplikaci potřeba (soubory cookie používá služba 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 middlewaru access_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í.
Existují omezení pro příchozí a odchozí zprávy, obě je možné nakonfigurovat u objektu HttpConnectionDispatcherOptions nakonfigurovaného v MapHub
:
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 aPOST
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 jsou soubory cookie, nejsou ve vaší aplikaci potřeba (soubory cookie používá služba 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 middlewaru access_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í.
Existují omezení pro příchozí a odchozí zprávy, obě je možné nakonfigurovat u objektu HttpConnectionDispatcherOptions nakonfigurovaného v MapHub
:
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 aPOST
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 jsou soubory cookie, nejsou ve vaší aplikaci potřeba (soubory cookie používá služba 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 UseSignalR
a 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 middlewaru access_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í.
Existují omezení pro příchozí a odchozí zprávy, obě je možné nakonfigurovat u objektu HttpConnectionDispatcherOptions nakonfigurovaného v MapHub
:
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í.