ASP.NET Core'da güvenlikle ilgili dikkat edilmesi gerekenler SignalR

Tarafından Andrew Stanton-Nurse

Bu makalede güvenliğini sağlama SignalRhakkında bilgi sağlanır.

Çıkış Noktaları Arası Kaynak Paylaşımı

Çıkış Noktaları Arası Kaynak Paylaşımı (CORS), tarayıcıda çıkış noktaları SignalR arası bağlantılara izin vermek için kullanılabilir. JavaScript kodu uygulamadan SignalR farklı bir etki alanında barındırılıyorsa, JavaScript'in uygulamaya bağlanmasına izin vermek için CORS ara yazılımının etkinleştirilmesi SignalR gerekir. Yalnızca güvendiğiniz veya denetlediğiniz etki alanlarından gelen çıkış noktaları arası isteklere izin verin. Örneğin:

  • Siteniz şu konumda barındırılıyor: http://www.example.com
  • Uygulamanız SignalR şu konumlarda barındırılıyor: http://signalr.example.com

CORS, uygulamada yalnızca kaynağına www.example.comizin verecek şekilde yapılandırılmalıdırSignalR.

CORS'yi yapılandırma hakkında daha fazla bilgi için bkz . Çıkış Noktaları Arası İstekleri (CORS) Etkinleştirme. SignalR aşağıdaki CORS ilkelerini gerektirir:

  • Belirli beklenen çıkış noktalarına izin verin. Herhangi bir kaynağın kullanılması mümkündür ancak güvenli değildir veya önerilmez.
  • HTTP yöntemlerine GETPOST izin verilmelidir.
  • Tabanlı yapışkan oturumların düzgün çalışması için cookiekimlik bilgilerine izin verilmelidir. Kimlik doğrulaması kullanılmadığında bile etkinleştirilmeleri gerekir.

Ancak, 5.0'da TypeScript istemcisinde kimlik bilgilerini kullanmama seçeneği sağladık. Kimlik bilgilerini kullanmama seçeneği yalnızca uygulamanızda s gibi Cookiekimlik bilgilerinin gerekli olmadığını %100 bildiğinizde kullanılmalıdır (cookiebunlar, yapışkan oturumlar için birden çok sunucu kullanılırken Azure App Service tarafından kullanılır).

Örneğin, aşağıdaki vurgulanmış CORS ilkesi, üzerinde barındırılan bir SignalR tarayıcı istemcisinin üzerinde https://signalr.example.combarındırılan SignalR uygulamaya erişmesine izin verir:https://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");

Önceki örnekte CORS ilkesi belirli kaynaklara, yöntemlere ve kimlik bilgilerine izin verecek şekilde özelleştirilir. ASP.NET Core'da CORS ilkelerini ve ara yazılımı özelleştirme hakkında daha fazla bilgi için bkz . CORS ara yazılımı: adlandırılmış ilke ve ara yazılım ile CORS.

WebSocket Kaynak Kısıtlaması

CORS tarafından sağlanan korumalar WebSockets için geçerli değildir. WebSockets'te kaynak kısıtlaması için Bkz . WebSockets kaynak kısıtlaması.

ConnectionId

ConnectionId Sunucu veya istemci sürümü Core 2.2 veya önceki bir sürüm ASP.NET kötü amaçlı kimliğe bürünmeye SignalR neden olabilir. SignalR Sunucu ve istemci sürümü Core 3.0 veya sonraki ASP.NET ise, ConnectionToken yerine ConnectionId gizli tutulmalıdır. ConnectionToken, herhangi bir API'de kasıtlı olarak kullanıma sunulmaz. Eski SignalR istemcilerin sunucuya bağlanmadığından emin olmak zor olabilir, bu nedenle sunucu sürümünüz SignalR Core 3.0 veya sonraki bir sürümü ASP.NET olsa bile, ConnectionId sunucunuzun kullanıma sunulmaması gerekir.

Erişim belirteci günlüğü

WebSockets veya Sunucu Tarafından Gönderilen Olaylar kullanılırken, tarayıcı istemcisi erişim belirtecini sorgu dizesinde gönderir. Erişim belirtecini sorgu dizesi aracılığıyla almak genellikle standart Authorization üst bilgi kullanmak kadar güvenlidir. İstemci ile sunucu arasında güvenli bir uçtan uca bağlantı sağlamak için her zaman HTTPS kullanın. Birçok web sunucusu, sorgu dizesi de dahil olmak üzere her isteğin URL'sini günlüğe kaydeder. URL'lerin günlüğe kaydedilmesi erişim belirtecini günlüğe kaydedebilir. ASP.NET Core, sorgu dizesini içeren her isteğin URL'sini varsayılan olarak günlüğe kaydeder. Örneğin:

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

Bu verileri sunucu günlüklerinizle günlüğe kaydetme konusunda endişeleriniz varsa günlükçü'leri Warning düzeye veya üstüne yapılandırarak Microsoft.AspNetCore.Hosting (bu iletiler düzeyde yazılırInfo) bu günlüğü tamamen devre dışı bırakabilirsiniz. Daha fazla bilgi için bkz . Koda günlük filtresi kuralları uygulama. Yine de belirli istek bilgilerini günlüğe kaydetmek istiyorsanız, ihtiyacınız olan verileri günlüğe kaydetmek için ara yazılım yazabilir ve sorgu dizesi değerini (varsa) filtreleyebilirsinizaccess_token.

Özel durumlar

Özel durum iletileri genellikle istemciye açılmaması gereken hassas veriler olarak kabul edilir. Varsayılan olarak, SignalR bir hub yöntemi tarafından oluşan özel durumun ayrıntılarını istemciye göndermez. Bunun yerine, istemci bir hata oluştuğunu belirten genel bir ileti alır. İstemciye özel durum iletisi teslimi EnableDetailedErrors ile geçersiz kılınabilir (örneğin geliştirme veya testte). Özel durum iletileri üretim uygulamalarında istemciye sunulmamalıdır.

Arabellek yönetimi

SignalR gelen ve giden iletileri yönetmek için bağlantı başına arabellekleri kullanır. Varsayılan olarak, SignalR bu arabellekleri 32 KB ile sınırlar. İstemcinin veya sunucunun gönderebileceği en büyük ileti 32 KB'tır. İletiler için bağlantı tarafından tüketilen bellek üst sınırı 32 KB'tır. İletileriniz her zaman 32 KB'tan küçükse sınırı azaltabilirsiniz:

  • İstemcinin daha büyük bir ileti gönderebilmesini engeller.
  • Sunucunun iletileri kabul etmek için hiçbir zaman büyük arabellekler ayırması gerekmez.

İletileriniz 32 KB'tan büyükse sınırı artırabilirsiniz. Bu sınırın artırılması şu anlama gelir:

  • İstemci, sunucunun büyük bellek arabellekleri ayırmasına neden olabilir.
  • Büyük arabelleklerin sunucu ayırması eşzamanlı bağlantı sayısını azaltabilir.

Gelen ve giden iletiler için sınırlar vardır; her ikisi de içinde yapılandırılan Http Bağlan ionDispatcherOptions nesnesinde MapHubyapılandırılabilir:

  • ApplicationMaxBufferSize , sunucunun arabelleğe alan istemciden en fazla bayt sayısını temsil eder. İstemci bu sınırdan daha büyük bir ileti göndermeye çalışırsa, bağlantı kapatılabilir.
  • TransportMaxBufferSize sunucunun gönderebileceği en fazla bayt sayısını temsil eder. Sunucu bu sınırdan daha büyük bir ileti (hub yöntemlerinden dönüş değerleri dahil) göndermeye çalışırsa, bir özel durum oluşturulur.

Sınırın ayarlanması, sınırı 0 devre dışı bırakır. Sınırın kaldırılması, istemcinin herhangi bir boyutta ileti göndermesine olanak tanır. Büyük iletiler gönderen kötü amaçlı istemciler fazla belleğin ayrılmasına neden olabilir. Fazla bellek kullanımı eşzamanlı bağlantı sayısını önemli ölçüde azaltabilir.

Bu makalede güvenliğini sağlama SignalRhakkında bilgi sağlanır.

Çıkış Noktaları Arası Kaynak Paylaşımı

Çıkış Noktaları Arası Kaynak Paylaşımı (CORS), tarayıcıda çıkış noktaları SignalR arası bağlantılara izin vermek için kullanılabilir. JavaScript kodu uygulamadan SignalR farklı bir etki alanında barındırılıyorsa, JavaScript'in uygulamaya bağlanmasına izin vermek için CORS ara yazılımının etkinleştirilmesi SignalR gerekir. Yalnızca güvendiğiniz veya denetlediğiniz etki alanlarından gelen çıkış noktaları arası isteklere izin verin. Örneğin:

  • Siteniz şu konumda barındırılıyor: http://www.example.com
  • Uygulamanız SignalR şu konumlarda barındırılıyor: http://signalr.example.com

CORS, uygulamada yalnızca kaynağına www.example.comizin verecek şekilde yapılandırılmalıdırSignalR.

CORS'yi yapılandırma hakkında daha fazla bilgi için bkz . Çıkış Noktaları Arası İstekleri (CORS) Etkinleştirme. SignalR aşağıdaki CORS ilkelerini gerektirir:

  • Belirli beklenen çıkış noktalarına izin verin. Herhangi bir kaynağın kullanılması mümkündür ancak güvenli değildir veya önerilmez.
  • HTTP yöntemlerine GETPOST izin verilmelidir.
  • Tabanlı yapışkan oturumların düzgün çalışması için cookiekimlik bilgilerine izin verilmelidir. Kimlik doğrulaması kullanılmadığında bile etkinleştirilmeleri gerekir.

Ancak, 5.0'da TypeScript istemcisinde kimlik bilgilerini kullanmama seçeneği sağladık. Kimlik bilgilerini kullanmama seçeneği yalnızca uygulamanızda s gibi Cookiekimlik bilgilerinin gerekli olmadığını %100 bildiğinizde kullanılmalıdır (cookiebunlar, yapışkan oturumlar için birden çok sunucu kullanılırken Azure App Service tarafından kullanılır).

Örneğin, aşağıdaki vurgulanmış CORS ilkesi, üzerinde barındırılan bir SignalR tarayıcı istemcisinin üzerinde https://signalr.example.combarındırılan SignalR uygulamaya erişmesine izin verir:https://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");

Önceki örnekte CORS ilkesi belirli kaynaklara, yöntemlere ve kimlik bilgilerine izin verecek şekilde özelleştirilir. ASP.NET Core'da CORS ilkelerini ve ara yazılımı özelleştirme hakkında daha fazla bilgi için bkz . CORS ara yazılımı: adlandırılmış ilke ve ara yazılım ile CORS.

WebSocket Kaynak Kısıtlaması

CORS tarafından sağlanan korumalar WebSockets için geçerli değildir. WebSockets'te kaynak kısıtlaması için Bkz . WebSockets kaynak kısıtlaması.

ConnectionId

ConnectionId Sunucu veya istemci sürümü Core 2.2 veya önceki bir sürüm ASP.NET kötü amaçlı kimliğe bürünmeye SignalR neden olabilir. SignalR Sunucu ve istemci sürümü Core 3.0 veya sonraki ASP.NET ise, ConnectionToken yerine ConnectionId gizli tutulmalıdır. ConnectionToken, herhangi bir API'de kasıtlı olarak kullanıma sunulmaz. Eski SignalR istemcilerin sunucuya bağlanmadığından emin olmak zor olabilir, bu nedenle sunucu sürümünüz SignalR Core 3.0 veya sonraki bir sürümü ASP.NET olsa bile, ConnectionId sunucunuzun kullanıma sunulmaması gerekir.

Erişim belirteci günlüğü

WebSockets veya Sunucu Tarafından Gönderilen Olaylar kullanılırken, tarayıcı istemcisi erişim belirtecini sorgu dizesinde gönderir. Erişim belirtecini sorgu dizesi aracılığıyla almak genellikle standart Authorization üst bilgi kullanmak kadar güvenlidir. İstemci ile sunucu arasında güvenli bir uçtan uca bağlantı sağlamak için her zaman HTTPS kullanın. Birçok web sunucusu, sorgu dizesi de dahil olmak üzere her isteğin URL'sini günlüğe kaydeder. URL'lerin günlüğe kaydedilmesi erişim belirtecini günlüğe kaydedebilir. ASP.NET Core, sorgu dizesini içeren her isteğin URL'sini varsayılan olarak günlüğe kaydeder. Örneğin:

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

Bu verileri sunucu günlüklerinizle günlüğe kaydetme konusunda endişeleriniz varsa günlükçü'leri Warning düzeye veya üstüne yapılandırarak Microsoft.AspNetCore.Hosting (bu iletiler düzeyde yazılırInfo) bu günlüğü tamamen devre dışı bırakabilirsiniz. Daha fazla bilgi için bkz . Koda günlük filtresi kuralları uygulama. Yine de belirli istek bilgilerini günlüğe kaydetmek istiyorsanız, ihtiyacınız olan verileri günlüğe kaydetmek için ara yazılım yazabilir ve sorgu dizesi değerini (varsa) filtreleyebilirsinizaccess_token.

Özel durumlar

Özel durum iletileri genellikle istemciye açılmaması gereken hassas veriler olarak kabul edilir. Varsayılan olarak, SignalR bir hub yöntemi tarafından oluşan özel durumun ayrıntılarını istemciye göndermez. Bunun yerine, istemci bir hata oluştuğunu belirten genel bir ileti alır. İstemciye özel durum iletisi teslimi EnableDetailedErrors ile geçersiz kılınabilir (örneğin geliştirme veya testte). Özel durum iletileri üretim uygulamalarında istemciye sunulmamalıdır.

Arabellek yönetimi

SignalR gelen ve giden iletileri yönetmek için bağlantı başına arabellekleri kullanır. Varsayılan olarak, SignalR bu arabellekleri 32 KB ile sınırlar. İstemcinin veya sunucunun gönderebileceği en büyük ileti 32 KB'tır. İletiler için bağlantı tarafından tüketilen bellek üst sınırı 32 KB'tır. İletileriniz her zaman 32 KB'tan küçükse sınırı azaltabilirsiniz:

  • İstemcinin daha büyük bir ileti gönderebilmesini engeller.
  • Sunucunun iletileri kabul etmek için hiçbir zaman büyük arabellekler ayırması gerekmez.

İletileriniz 32 KB'tan büyükse sınırı artırabilirsiniz. Bu sınırın artırılması şu anlama gelir:

  • İstemci, sunucunun büyük bellek arabellekleri ayırmasına neden olabilir.
  • Büyük arabelleklerin sunucu ayırması eşzamanlı bağlantı sayısını azaltabilir.

Gelen ve giden iletiler için sınırlar vardır; her ikisi de içinde yapılandırılan Http Bağlan ionDispatcherOptions nesnesinde MapHubyapılandırılabilir:

  • ApplicationMaxBufferSize , sunucunun arabelleğe alan istemciden en fazla bayt sayısını temsil eder. İstemci bu sınırdan daha büyük bir ileti göndermeye çalışırsa, bağlantı kapatılabilir.
  • TransportMaxBufferSize sunucunun gönderebileceği en fazla bayt sayısını temsil eder. Sunucu bu sınırdan daha büyük bir ileti (hub yöntemlerinden dönüş değerleri dahil) göndermeye çalışırsa, bir özel durum oluşturulur.

Sınırın ayarlanması, sınırı 0 devre dışı bırakır. Sınırın kaldırılması, istemcinin herhangi bir boyutta ileti göndermesine olanak tanır. Büyük iletiler gönderen kötü amaçlı istemciler fazla belleğin ayrılmasına neden olabilir. Fazla bellek kullanımı eşzamanlı bağlantı sayısını önemli ölçüde azaltabilir.

Bu makalede güvenliğini sağlama SignalRhakkında bilgi sağlanır.

Çıkış Noktaları Arası Kaynak Paylaşımı

Çıkış Noktaları Arası Kaynak Paylaşımı (CORS), tarayıcıda çıkış noktaları SignalR arası bağlantılara izin vermek için kullanılabilir. JavaScript kodu uygulamadan SignalR farklı bir etki alanında barındırılıyorsa, JavaScript'in uygulamaya bağlanmasına izin vermek için CORS ara yazılımının etkinleştirilmesi SignalR gerekir. Yalnızca güvendiğiniz veya denetlediğiniz etki alanlarından gelen çıkış noktaları arası isteklere izin verin. Örneğin:

  • Siteniz şu konumda barındırılıyor: http://www.example.com
  • Uygulamanız SignalR şu konumlarda barındırılıyor: http://signalr.example.com

CORS, uygulamada yalnızca kaynağına www.example.comizin verecek şekilde yapılandırılmalıdırSignalR.

CORS'yi yapılandırma hakkında daha fazla bilgi için bkz . Çıkış Noktaları Arası İstekleri (CORS) Etkinleştirme. SignalR aşağıdaki CORS ilkelerini gerektirir:

  • Belirli beklenen çıkış noktalarına izin verin. Herhangi bir kaynağın kullanılması mümkündür ancak güvenli değildir veya önerilmez.
  • HTTP yöntemlerine GETPOST izin verilmelidir.
  • Tabanlı yapışkan oturumların düzgün çalışması için cookiekimlik bilgilerine izin verilmelidir. Kimlik doğrulaması kullanılmadığında bile etkinleştirilmeleri gerekir.

Ancak, 5.0'da TypeScript istemcisinde kimlik bilgilerini kullanmama seçeneği sağladık. Kimlik bilgilerini kullanmama seçeneği yalnızca uygulamanızda s gibi Cookiekimlik bilgilerinin gerekli olmadığını %100 bildiğinizde kullanılmalıdır (cookiebunlar, yapışkan oturumlar için birden çok sunucu kullanılırken Azure App Service tarafından kullanılır).

Örneğin, aşağıdaki vurgulanmış CORS ilkesi, üzerinde barındırılan bir SignalR tarayıcı istemcisinin üzerinde https://signalr.example.combarındırılan SignalR uygulamaya erişmesine izin verir:https://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");

Önceki örnekte CORS ilkesi belirli kaynaklara, yöntemlere ve kimlik bilgilerine izin verecek şekilde özelleştirilir. ASP.NET Core'da CORS ilkelerini ve ara yazılımı özelleştirme hakkında daha fazla bilgi için bkz . CORS ara yazılımı: adlandırılmış ilke ve ara yazılım ile CORS.

WebSocket Kaynak Kısıtlaması

CORS tarafından sağlanan korumalar WebSockets için geçerli değildir. WebSockets'te kaynak kısıtlaması için Bkz . WebSockets kaynak kısıtlaması.

ConnectionId

ConnectionId Sunucu veya istemci sürümü Core 2.2 veya önceki bir sürüm ASP.NET kötü amaçlı kimliğe bürünmeye SignalR neden olabilir. SignalR Sunucu ve istemci sürümü Core 3.0 veya sonraki ASP.NET ise, ConnectionToken yerine ConnectionId gizli tutulmalıdır. ConnectionToken, herhangi bir API'de kasıtlı olarak kullanıma sunulmaz. Eski SignalR istemcilerin sunucuya bağlanmadığından emin olmak zor olabilir, bu nedenle sunucu sürümünüz SignalR Core 3.0 veya sonraki bir sürümü ASP.NET olsa bile, ConnectionId sunucunuzun kullanıma sunulmaması gerekir.

Erişim belirteci günlüğü

WebSockets veya Sunucu Tarafından Gönderilen Olaylar kullanılırken, tarayıcı istemcisi erişim belirtecini sorgu dizesinde gönderir. Erişim belirtecini sorgu dizesi aracılığıyla almak genellikle standart Authorization üst bilgi kullanmak kadar güvenlidir. İstemci ile sunucu arasında güvenli bir uçtan uca bağlantı sağlamak için her zaman HTTPS kullanın. Birçok web sunucusu, sorgu dizesi de dahil olmak üzere her isteğin URL'sini günlüğe kaydeder. URL'lerin günlüğe kaydedilmesi erişim belirtecini günlüğe kaydedebilir. ASP.NET Core, sorgu dizesini içeren her isteğin URL'sini varsayılan olarak günlüğe kaydeder. Örneğin:

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

Bu verileri sunucu günlüklerinizle günlüğe kaydetme konusunda endişeleriniz varsa günlükçü'leri Warning düzeye veya üstüne yapılandırarak Microsoft.AspNetCore.Hosting (bu iletiler düzeyde yazılırInfo) bu günlüğü tamamen devre dışı bırakabilirsiniz. Daha fazla bilgi için bkz . Koda günlük filtresi kuralları uygulama. Yine de belirli istek bilgilerini günlüğe kaydetmek istiyorsanız, ihtiyacınız olan verileri günlüğe kaydetmek için ara yazılım yazabilir ve sorgu dizesi değerini (varsa) filtreleyebilirsinizaccess_token.

Özel durumlar

Özel durum iletileri genellikle istemciye açılmaması gereken hassas veriler olarak kabul edilir. Varsayılan olarak, SignalR bir hub yöntemi tarafından oluşan özel durumun ayrıntılarını istemciye göndermez. Bunun yerine, istemci bir hata oluştuğunu belirten genel bir ileti alır. İstemciye özel durum iletisi teslimi EnableDetailedErrors ile geçersiz kılınabilir (örneğin geliştirme veya testte). Özel durum iletileri üretim uygulamalarında istemciye sunulmamalıdır.

Arabellek yönetimi

SignalR gelen ve giden iletileri yönetmek için bağlantı başına arabellekleri kullanır. Varsayılan olarak, SignalR bu arabellekleri 32 KB ile sınırlar. İstemcinin veya sunucunun gönderebileceği en büyük ileti 32 KB'tır. İletiler için bağlantı tarafından tüketilen bellek üst sınırı 32 KB'tır. İletileriniz her zaman 32 KB'tan küçükse sınırı azaltabilirsiniz:

  • İstemcinin daha büyük bir ileti gönderebilmesini engeller.
  • Sunucunun iletileri kabul etmek için hiçbir zaman büyük arabellekler ayırması gerekmez.

İletileriniz 32 KB'tan büyükse sınırı artırabilirsiniz. Bu sınırın artırılması şu anlama gelir:

  • İstemci, sunucunun büyük bellek arabellekleri ayırmasına neden olabilir.
  • Büyük arabelleklerin sunucu ayırması eşzamanlı bağlantı sayısını azaltabilir.

Gelen ve giden iletiler için sınırlar vardır; her ikisi de içinde yapılandırılan Http Bağlan ionDispatcherOptions nesnesinde MapHubyapılandırılabilir:

  • ApplicationMaxBufferSize , sunucunun arabelleğe alan istemciden en fazla bayt sayısını temsil eder. İstemci bu sınırdan daha büyük bir ileti göndermeye çalışırsa, bağlantı kapatılabilir.
  • TransportMaxBufferSize sunucunun gönderebileceği en fazla bayt sayısını temsil eder. Sunucu bu sınırdan daha büyük bir ileti (hub yöntemlerinden dönüş değerleri dahil) göndermeye çalışırsa, bir özel durum oluşturulur.

Sınırın ayarlanması, sınırı 0 devre dışı bırakır. Sınırın kaldırılması, istemcinin herhangi bir boyutta ileti göndermesine olanak tanır. Büyük iletiler gönderen kötü amaçlı istemciler fazla belleğin ayrılmasına neden olabilir. Fazla bellek kullanımı eşzamanlı bağlantı sayısını önemli ölçüde azaltabilir.

Bu makalede güvenliğini sağlama SignalRhakkında bilgi sağlanır.

Çıkış Noktaları Arası Kaynak Paylaşımı

Çıkış Noktaları Arası Kaynak Paylaşımı (CORS), tarayıcıda çıkış noktaları SignalR arası bağlantılara izin vermek için kullanılabilir. JavaScript kodu uygulamadan SignalR farklı bir etki alanında barındırılıyorsa, JavaScript'in uygulamaya bağlanmasına izin vermek için CORS ara yazılımının etkinleştirilmesi SignalR gerekir. Yalnızca güvendiğiniz veya denetlediğiniz etki alanlarından gelen çıkış noktaları arası isteklere izin verin. Örneğin:

  • Siteniz şu konumda barındırılıyor: http://www.example.com
  • Uygulamanız SignalR şu konumlarda barındırılıyor: http://signalr.example.com

CORS, uygulamada yalnızca kaynağına www.example.comizin verecek şekilde yapılandırılmalıdırSignalR.

CORS'yi yapılandırma hakkında daha fazla bilgi için bkz . Çıkış Noktaları Arası İstekleri (CORS) Etkinleştirme. SignalR aşağıdaki CORS ilkelerini gerektirir:

  • Belirli beklenen çıkış noktalarına izin verin. Herhangi bir kaynağın kullanılması mümkündür ancak güvenli değildir veya önerilmez.
  • HTTP yöntemlerine GETPOST izin verilmelidir.
  • Tabanlı yapışkan oturumların düzgün çalışması için cookiekimlik bilgilerine izin verilmelidir. Kimlik doğrulaması kullanılmadığında bile etkinleştirilmeleri gerekir.

Ancak, 5.0'da TypeScript istemcisinde kimlik bilgilerini kullanmama seçeneği sağladık. Kimlik bilgilerini kullanmama seçeneği yalnızca uygulamanızda s gibi Cookiekimlik bilgilerinin gerekli olmadığını %100 bildiğinizde kullanılmalıdır (cookiebunlar, yapışkan oturumlar için birden çok sunucu kullanılırken Azure App Service tarafından kullanılır).

Örneğin, aşağıdaki CORS ilkesi üzerinde https://example.com barındırılan bir SignalR tarayıcı istemcisinin üzerinde https://signalr.example.combarındırılan SignalR uygulamaya erişmesine izin verir:

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 ...
}

WebSocket Kaynak Kısıtlaması

CORS tarafından sağlanan korumalar WebSockets için geçerli değildir. WebSockets'te kaynak kısıtlaması için Bkz . WebSockets kaynak kısıtlaması.

CORS tarafından sağlanan korumalar WebSockets için geçerli değildir. Tarayıcılar aşağıdakileri yapmaz:

  • CORS uçuş öncesi istekleri gerçekleştirin.
  • WebSocket istekleri yaparken üst bilgilerde Access-Control belirtilen kısıtlamalara uyun.

Ancak tarayıcılar WebSocket istekleri gönderirken üst bilgiyi gönderir Origin . Uygulamalar, yalnızca beklenen kaynaklardan gelen WebSockets'e izin verildiğinden emin olmak için bu üst bilgileri doğrulayacak şekilde yapılandırılmalıdır.

ASP.NET Core 2.1 ve sonraki sürümlerde, üst bilgi doğrulamasından önce yerleştirilen özel bir ara yazılım ve içinde Configurekimlik doğrulaması ara yazılımı kullanılarak gerçekleştirilebilir:UseSignalR


// 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 ...
}

Not

Üst Origin bilgi istemci tarafından denetlenebilir ve üst bilgi gibi Referer sahte olabilir. Bu üst bilgiler kimlik doğrulama mekanizması olarak kullanılmamalıdır.

ConnectionId

ConnectionId Sunucu veya istemci sürümü Core 2.2 veya önceki bir sürüm ASP.NET kötü amaçlı kimliğe bürünmeye SignalR neden olabilir. SignalR Sunucu ve istemci sürümü Core 3.0 veya sonraki ASP.NET ise, ConnectionToken yerine ConnectionId gizli tutulmalıdır. ConnectionToken, herhangi bir API'de kasıtlı olarak kullanıma sunulmaz. Eski SignalR istemcilerin sunucuya bağlanmadığından emin olmak zor olabilir, bu nedenle sunucu sürümünüz SignalR Core 3.0 veya sonraki bir sürümü ASP.NET olsa bile, ConnectionId sunucunuzun kullanıma sunulmaması gerekir.

Erişim belirteci günlüğü

WebSockets veya Sunucu Tarafından Gönderilen Olaylar kullanılırken, tarayıcı istemcisi erişim belirtecini sorgu dizesinde gönderir. Erişim belirtecini sorgu dizesi aracılığıyla almak genellikle standart Authorization üst bilgi kullanmak kadar güvenlidir. İstemci ile sunucu arasında güvenli bir uçtan uca bağlantı sağlamak için her zaman HTTPS kullanın. Birçok web sunucusu, sorgu dizesi de dahil olmak üzere her isteğin URL'sini günlüğe kaydeder. URL'lerin günlüğe kaydedilmesi erişim belirtecini günlüğe kaydedebilir. ASP.NET Core, sorgu dizesini içeren her isteğin URL'sini varsayılan olarak günlüğe kaydeder. Örneğin:

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

Bu verileri sunucu günlüklerinizle günlüğe kaydetme konusunda endişeleriniz varsa günlükçü'leri Warning düzeye veya üstüne yapılandırarak Microsoft.AspNetCore.Hosting (bu iletiler düzeyde yazılırInfo) bu günlüğü tamamen devre dışı bırakabilirsiniz. Daha fazla bilgi için bkz . Koda günlük filtresi kuralları uygulama. Yine de belirli istek bilgilerini günlüğe kaydetmek istiyorsanız, ihtiyacınız olan verileri günlüğe kaydetmek için ara yazılım yazabilir ve sorgu dizesi değerini (varsa) filtreleyebilirsinizaccess_token.

Özel durumlar

Özel durum iletileri genellikle istemciye açılmaması gereken hassas veriler olarak kabul edilir. Varsayılan olarak, SignalR bir hub yöntemi tarafından oluşan özel durumun ayrıntılarını istemciye göndermez. Bunun yerine, istemci bir hata oluştuğunu belirten genel bir ileti alır. İstemciye özel durum iletisi teslimi EnableDetailedErrors ile geçersiz kılınabilir (örneğin geliştirme veya testte). Özel durum iletileri üretim uygulamalarında istemciye sunulmamalıdır.

Arabellek yönetimi

SignalR gelen ve giden iletileri yönetmek için bağlantı başına arabellekleri kullanır. Varsayılan olarak, SignalR bu arabellekleri 32 KB ile sınırlar. İstemcinin veya sunucunun gönderebileceği en büyük ileti 32 KB'tır. İletiler için bağlantı tarafından tüketilen bellek üst sınırı 32 KB'tır. İletileriniz her zaman 32 KB'tan küçükse sınırı azaltabilirsiniz:

  • İstemcinin daha büyük bir ileti gönderebilmesini engeller.
  • Sunucunun iletileri kabul etmek için hiçbir zaman büyük arabellekler ayırması gerekmez.

İletileriniz 32 KB'tan büyükse sınırı artırabilirsiniz. Bu sınırın artırılması şu anlama gelir:

  • İstemci, sunucunun büyük bellek arabellekleri ayırmasına neden olabilir.
  • Büyük arabelleklerin sunucu ayırması eşzamanlı bağlantı sayısını azaltabilir.

Gelen ve giden iletiler için sınırlar vardır; her ikisi de içinde yapılandırılan Http Bağlan ionDispatcherOptions nesnesinde MapHubyapılandırılabilir:

  • ApplicationMaxBufferSize , sunucunun arabelleğe alan istemciden en fazla bayt sayısını temsil eder. İstemci bu sınırdan daha büyük bir ileti göndermeye çalışırsa, bağlantı kapatılabilir.
  • TransportMaxBufferSize sunucunun gönderebileceği en fazla bayt sayısını temsil eder. Sunucu bu sınırdan daha büyük bir ileti (hub yöntemlerinden dönüş değerleri dahil) göndermeye çalışırsa, bir özel durum oluşturulur.

Sınırın ayarlanması, sınırı 0 devre dışı bırakır. Sınırın kaldırılması, istemcinin herhangi bir boyutta ileti göndermesine olanak tanır. Büyük iletiler gönderen kötü amaçlı istemciler fazla belleğin ayrılmasına neden olabilir. Fazla bellek kullanımı eşzamanlı bağlantı sayısını önemli ölçüde azaltabilir.