Bagikan melalui


Pertimbangan keamanan di ASP.NET Core SignalR

Oleh Andrew Stanton-Perawat

Artikel ini menyediakan informasi tentang mengamankan SignalR.

Berbagi Sumber Daya Lintas-Asal

Cross-Origin Resource Sharing (CORS) dapat digunakan untuk mengizinkan koneksi lintas asal SignalR di browser. Jika kode JavaScript dihosting di domain yang berbeda dari SignalR aplikasi, middleware CORS harus diaktifkan untuk memungkinkan JavaScript terhubung ke SignalR aplikasi. Izinkan permintaan lintas asal hanya dari domain yang Anda percayai atau kontrol. Misalnya:

  • Situs Anda dihosting di http://www.example.com
  • Aplikasi Anda SignalR dihosting di http://signalr.example.com

CORS harus dikonfigurasi di SignalR aplikasi untuk hanya mengizinkan asal www.example.com.

Untuk informasi selengkapnya tentang mengonfigurasi CORS, lihat Mengaktifkan Permintaan Lintas Asal (CORS). SignalR memerlukan kebijakan CORS berikut:

  • Izinkan asal spesifik yang diharapkan. Mengizinkan asal apa pun dimungkinkan tetapi tidak aman atau direkomendasikan.
  • Metode GET HTTP dan POST harus diizinkan.
  • Kredensial harus diizinkan agar cookiesesi lengket berbasis berfungsi dengan benar. Mereka harus diaktifkan bahkan ketika autentikasi tidak digunakan.

Namun, di 5.0 kami telah menyediakan opsi di klien TypeScript untuk tidak menggunakan kredensial. Opsi untuk tidak menggunakan kredensial hanya boleh digunakan saat Anda mengetahui 100% kredensial seperti Cookies tidak diperlukan di aplikasi Anda (cookiedigunakan oleh layanan aplikasi azure saat menggunakan beberapa server untuk sesi lengket).

Misalnya, kebijakan CORS yang disorot berikut memungkinkan klien browser yang SignalR dihosting https://example.com untuk mengakses aplikasi yang SignalR dihosting di 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");

Dalam contoh sebelumnya, kebijakan CORS disesuaikan untuk memungkinkan asal, metode, dan kredensial tertentu. Untuk informasi selengkapnya tentang menyesuaikan kebijakan CORS dan middleware di ASP.NET Core, lihat middleware CORS: CORS dengan kebijakan dan middleware bernama.

Pembatasan Asal WebSocket

Perlindungan yang diberikan oleh CORS tidak berlaku untuk WebSocket. Untuk pembatasan asal pada WebSocket, baca Pembatasan asal WebSockets.

ConnectionId

Mengekspos ConnectionId dapat menyebabkan peniruan berbahaya jika SignalR server atau versi klien ASP.NET Core 2.2 atau yang lebih lama. SignalR Jika server dan versi klien ASP.NET Core 3.0 atau yang lebih baru, ConnectionToken bukan ConnectionId harus dirahasiakan. ConnectionToken tujuannya tidak diekspos di API apa pun. Mungkin sulit untuk memastikan bahwa klien yang lebih SignalR lama tidak terhubung ke server, jadi bahkan jika versi server Anda SignalR ASP.NET Core 3.0 atau yang lebih baru, ConnectionId seharusnya tidak diekspos.

Pengelogan token akses

Saat menggunakan WebSockets atau Server-Sent Events, klien browser mengirim token akses dalam string kueri. Menerima token akses melalui string kueri umumnya seaman menggunakan header standar Authorization . Selalu gunakan HTTPS untuk memastikan koneksi end-to-end yang aman antara klien dan server. Banyak server web mencatat URL untuk setiap permintaan, termasuk string kueri. Pengelogan URL dapat mencatat token akses. ASP.NET Core mencatat URL untuk setiap permintaan secara default, yang menyertakan string kueri. Misalnya:

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

Jika Anda memiliki kekhawatiran tentang pengelogan data ini dengan log server Anda, Anda dapat menonaktifkan pengelogan ini sepenuhnya dengan mengonfigurasi pencatat Microsoft.AspNetCore.Hosting ke Warning tingkat atau di atasnya (pesan ini ditulis pada Info tingkat). Untuk informasi selengkapnya, lihat Menerapkan aturan filter log dalam kode untuk informasi selengkapnya. Jika Anda masih ingin mencatat informasi permintaan tertentu, Anda dapat menulis middleware untuk mencatat data yang Anda butuhkan dan memfilter access_token nilai string kueri (jika ada).

Pengecualian

Pesan pengecualian umumnya dianggap sebagai data sensitif yang seharusnya tidak diungkapkan kepada klien. Secara default, SignalR tidak mengirim detail pengecualian yang dilemparkan oleh metode hub ke klien. Sebagai gantinya, klien menerima pesan generik yang menunjukkan terjadinya kesalahan. Pengiriman pesan pengecualian ke klien dapat ditimpa (misalnya dalam pengembangan atau pengujian) dengan EnableDetailedErrors. Pesan pengecualian tidak boleh diekspos ke klien di aplikasi produksi.

Manajemen buffer

SignalR menggunakan buffer per koneksi untuk mengelola pesan masuk dan keluar. Secara default, SignalR membatasi buffer ini hingga 32 KB. Pesan terbesar yang dapat dikirim klien atau server adalah 32 KB. Memori maksimum yang digunakan oleh koneksi untuk pesan adalah 32 KB. Jika pesan Anda selalu lebih kecil dari 32 KB, Anda dapat mengurangi batas, yang:

  • Mencegah klien dapat mengirim pesan yang lebih besar.
  • Server tidak perlu mengalokasikan buffer besar untuk menerima pesan.

Jika pesan Anda lebih besar dari 32 KB, Anda dapat meningkatkan batas. Meningkatkan batas ini berarti:

  • Klien dapat menyebabkan server mengalokasikan buffer memori besar.
  • Alokasi server buffer besar dapat mengurangi jumlah koneksi bersamaan.

Ada batasan untuk pesan masuk dan keluar, keduanya dapat dikonfigurasi pada objek Http Koneksi ionDispatcherOptions yang dikonfigurasi di MapHub:

  • ApplicationMaxBufferSize mewakili jumlah maksimum byte dari klien yang di-buffer server. Jika klien mencoba mengirim pesan yang lebih besar dari batas ini, koneksi mungkin ditutup.
  • TransportMaxBufferSize mewakili jumlah maksimum byte yang dapat dikirim server. Jika server mencoba mengirim pesan (termasuk nilai pengembalian dari metode hub) yang lebih besar dari batas ini, pengecualian akan dilemparkan.

Mengatur batas untuk 0 menonaktifkan batas. Menghapus batas memungkinkan klien mengirim pesan dengan ukuran apa pun. Klien berbahaya yang mengirim pesan besar dapat menyebabkan kelebihan memori dialokasikan. Penggunaan memori berlebih dapat secara signifikan mengurangi jumlah koneksi bersamaan.

Artikel ini menyediakan informasi tentang mengamankan SignalR.

Berbagi Sumber Daya Lintas-Asal

Cross-Origin Resource Sharing (CORS) dapat digunakan untuk mengizinkan koneksi lintas asal SignalR di browser. Jika kode JavaScript dihosting di domain yang berbeda dari SignalR aplikasi, middleware CORS harus diaktifkan untuk memungkinkan JavaScript terhubung ke SignalR aplikasi. Izinkan permintaan lintas asal hanya dari domain yang Anda percayai atau kontrol. Misalnya:

  • Situs Anda dihosting di http://www.example.com
  • Aplikasi Anda SignalR dihosting di http://signalr.example.com

CORS harus dikonfigurasi di SignalR aplikasi untuk hanya mengizinkan asal www.example.com.

Untuk informasi selengkapnya tentang mengonfigurasi CORS, lihat Mengaktifkan Permintaan Lintas Asal (CORS). SignalR memerlukan kebijakan CORS berikut:

  • Izinkan asal spesifik yang diharapkan. Mengizinkan asal apa pun dimungkinkan tetapi tidak aman atau direkomendasikan.
  • Metode GET HTTP dan POST harus diizinkan.
  • Kredensial harus diizinkan agar cookiesesi lengket berbasis berfungsi dengan benar. Mereka harus diaktifkan bahkan ketika autentikasi tidak digunakan.

Namun, di 5.0 kami telah menyediakan opsi di klien TypeScript untuk tidak menggunakan kredensial. Opsi untuk tidak menggunakan kredensial hanya boleh digunakan saat Anda mengetahui 100% kredensial seperti Cookies tidak diperlukan di aplikasi Anda (cookiedigunakan oleh layanan aplikasi azure saat menggunakan beberapa server untuk sesi lengket).

Misalnya, kebijakan CORS yang disorot berikut memungkinkan klien browser yang SignalR dihosting https://example.com untuk mengakses aplikasi yang SignalR dihosting di 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");

Dalam contoh sebelumnya, kebijakan CORS disesuaikan untuk memungkinkan asal, metode, dan kredensial tertentu. Untuk informasi selengkapnya tentang menyesuaikan kebijakan CORS dan middleware di ASP.NET Core, lihat middleware CORS: CORS dengan kebijakan dan middleware bernama.

Pembatasan Asal WebSocket

Perlindungan yang diberikan oleh CORS tidak berlaku untuk WebSocket. Untuk pembatasan asal pada WebSocket, baca Pembatasan asal WebSockets.

ConnectionId

Mengekspos ConnectionId dapat menyebabkan peniruan berbahaya jika SignalR server atau versi klien ASP.NET Core 2.2 atau yang lebih lama. SignalR Jika server dan versi klien ASP.NET Core 3.0 atau yang lebih baru, ConnectionToken bukan ConnectionId harus dirahasiakan. ConnectionToken tujuannya tidak diekspos di API apa pun. Mungkin sulit untuk memastikan bahwa klien yang lebih SignalR lama tidak terhubung ke server, jadi bahkan jika versi server Anda SignalR ASP.NET Core 3.0 atau yang lebih baru, ConnectionId seharusnya tidak diekspos.

Pengelogan token akses

Saat menggunakan WebSockets atau Server-Sent Events, klien browser mengirim token akses dalam string kueri. Menerima token akses melalui string kueri umumnya seaman menggunakan header standar Authorization . Selalu gunakan HTTPS untuk memastikan koneksi end-to-end yang aman antara klien dan server. Banyak server web mencatat URL untuk setiap permintaan, termasuk string kueri. Pengelogan URL dapat mencatat token akses. ASP.NET Core mencatat URL untuk setiap permintaan secara default, yang menyertakan string kueri. Misalnya:

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

Jika Anda memiliki kekhawatiran tentang pengelogan data ini dengan log server Anda, Anda dapat menonaktifkan pengelogan ini sepenuhnya dengan mengonfigurasi pencatat Microsoft.AspNetCore.Hosting ke Warning tingkat atau di atasnya (pesan ini ditulis pada Info tingkat). Untuk informasi selengkapnya, lihat Menerapkan aturan filter log dalam kode untuk informasi selengkapnya. Jika Anda masih ingin mencatat informasi permintaan tertentu, Anda dapat menulis middleware untuk mencatat data yang Anda butuhkan dan memfilter access_token nilai string kueri (jika ada).

Pengecualian

Pesan pengecualian umumnya dianggap sebagai data sensitif yang seharusnya tidak diungkapkan kepada klien. Secara default, SignalR tidak mengirim detail pengecualian yang dilemparkan oleh metode hub ke klien. Sebagai gantinya, klien menerima pesan generik yang menunjukkan terjadinya kesalahan. Pengiriman pesan pengecualian ke klien dapat ditimpa (misalnya dalam pengembangan atau pengujian) dengan EnableDetailedErrors. Pesan pengecualian tidak boleh diekspos ke klien di aplikasi produksi.

Manajemen buffer

SignalR menggunakan buffer per koneksi untuk mengelola pesan masuk dan keluar. Secara default, SignalR membatasi buffer ini hingga 32 KB. Pesan terbesar yang dapat dikirim klien atau server adalah 32 KB. Memori maksimum yang digunakan oleh koneksi untuk pesan adalah 32 KB. Jika pesan Anda selalu lebih kecil dari 32 KB, Anda dapat mengurangi batas, yang:

  • Mencegah klien dapat mengirim pesan yang lebih besar.
  • Server tidak perlu mengalokasikan buffer besar untuk menerima pesan.

Jika pesan Anda lebih besar dari 32 KB, Anda dapat meningkatkan batas. Meningkatkan batas ini berarti:

  • Klien dapat menyebabkan server mengalokasikan buffer memori besar.
  • Alokasi server buffer besar dapat mengurangi jumlah koneksi bersamaan.

Ada batasan untuk pesan masuk dan keluar, keduanya dapat dikonfigurasi pada objek Http Koneksi ionDispatcherOptions yang dikonfigurasi di MapHub:

  • ApplicationMaxBufferSize mewakili jumlah maksimum byte dari klien yang di-buffer server. Jika klien mencoba mengirim pesan yang lebih besar dari batas ini, koneksi mungkin ditutup.
  • TransportMaxBufferSize mewakili jumlah maksimum byte yang dapat dikirim server. Jika server mencoba mengirim pesan (termasuk nilai pengembalian dari metode hub) yang lebih besar dari batas ini, pengecualian akan dilemparkan.

Mengatur batas untuk 0 menonaktifkan batas. Menghapus batas memungkinkan klien mengirim pesan dengan ukuran apa pun. Klien berbahaya yang mengirim pesan besar dapat menyebabkan kelebihan memori dialokasikan. Penggunaan memori berlebih dapat secara signifikan mengurangi jumlah koneksi bersamaan.

Artikel ini menyediakan informasi tentang mengamankan SignalR.

Berbagi Sumber Daya Lintas-Asal

Cross-Origin Resource Sharing (CORS) dapat digunakan untuk mengizinkan koneksi lintas asal SignalR di browser. Jika kode JavaScript dihosting di domain yang berbeda dari SignalR aplikasi, middleware CORS harus diaktifkan untuk memungkinkan JavaScript terhubung ke SignalR aplikasi. Izinkan permintaan lintas asal hanya dari domain yang Anda percayai atau kontrol. Misalnya:

  • Situs Anda dihosting di http://www.example.com
  • Aplikasi Anda SignalR dihosting di http://signalr.example.com

CORS harus dikonfigurasi di SignalR aplikasi untuk hanya mengizinkan asal www.example.com.

Untuk informasi selengkapnya tentang mengonfigurasi CORS, lihat Mengaktifkan Permintaan Lintas Asal (CORS). SignalR memerlukan kebijakan CORS berikut:

  • Izinkan asal spesifik yang diharapkan. Mengizinkan asal apa pun dimungkinkan tetapi tidak aman atau direkomendasikan.
  • Metode GET HTTP dan POST harus diizinkan.
  • Kredensial harus diizinkan agar cookiesesi lengket berbasis berfungsi dengan benar. Mereka harus diaktifkan bahkan ketika autentikasi tidak digunakan.

Namun, di 5.0 kami telah menyediakan opsi di klien TypeScript untuk tidak menggunakan kredensial. Opsi untuk tidak menggunakan kredensial hanya boleh digunakan saat Anda mengetahui 100% kredensial seperti Cookies tidak diperlukan di aplikasi Anda (cookiedigunakan oleh layanan aplikasi azure saat menggunakan beberapa server untuk sesi lengket).

Misalnya, kebijakan CORS yang disorot berikut memungkinkan klien browser yang SignalR dihosting https://example.com untuk mengakses aplikasi yang SignalR dihosting di 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");

Dalam contoh sebelumnya, kebijakan CORS disesuaikan untuk memungkinkan asal, metode, dan kredensial tertentu. Untuk informasi selengkapnya tentang menyesuaikan kebijakan CORS dan middleware di ASP.NET Core, lihat middleware CORS: CORS dengan kebijakan dan middleware bernama.

Pembatasan Asal WebSocket

Perlindungan yang diberikan oleh CORS tidak berlaku untuk WebSocket. Untuk pembatasan asal pada WebSocket, baca Pembatasan asal WebSockets.

ConnectionId

Mengekspos ConnectionId dapat menyebabkan peniruan berbahaya jika SignalR server atau versi klien ASP.NET Core 2.2 atau yang lebih lama. SignalR Jika server dan versi klien ASP.NET Core 3.0 atau yang lebih baru, ConnectionToken bukan ConnectionId harus dirahasiakan. ConnectionToken tujuannya tidak diekspos di API apa pun. Mungkin sulit untuk memastikan bahwa klien yang lebih SignalR lama tidak terhubung ke server, jadi bahkan jika versi server Anda SignalR ASP.NET Core 3.0 atau yang lebih baru, ConnectionId seharusnya tidak diekspos.

Pengelogan token akses

Saat menggunakan WebSockets atau Server-Sent Events, klien browser mengirim token akses dalam string kueri. Menerima token akses melalui string kueri umumnya seaman menggunakan header standar Authorization . Selalu gunakan HTTPS untuk memastikan koneksi end-to-end yang aman antara klien dan server. Banyak server web mencatat URL untuk setiap permintaan, termasuk string kueri. Pengelogan URL dapat mencatat token akses. ASP.NET Core mencatat URL untuk setiap permintaan secara default, yang menyertakan string kueri. Misalnya:

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

Jika Anda memiliki kekhawatiran tentang pengelogan data ini dengan log server Anda, Anda dapat menonaktifkan pengelogan ini sepenuhnya dengan mengonfigurasi pencatat Microsoft.AspNetCore.Hosting ke Warning tingkat atau di atasnya (pesan ini ditulis pada Info tingkat). Untuk informasi selengkapnya, lihat Menerapkan aturan filter log dalam kode untuk informasi selengkapnya. Jika Anda masih ingin mencatat informasi permintaan tertentu, Anda dapat menulis middleware untuk mencatat data yang Anda butuhkan dan memfilter access_token nilai string kueri (jika ada).

Pengecualian

Pesan pengecualian umumnya dianggap sebagai data sensitif yang seharusnya tidak diungkapkan kepada klien. Secara default, SignalR tidak mengirim detail pengecualian yang dilemparkan oleh metode hub ke klien. Sebagai gantinya, klien menerima pesan generik yang menunjukkan terjadinya kesalahan. Pengiriman pesan pengecualian ke klien dapat ditimpa (misalnya dalam pengembangan atau pengujian) dengan EnableDetailedErrors. Pesan pengecualian tidak boleh diekspos ke klien di aplikasi produksi.

Manajemen buffer

SignalR menggunakan buffer per koneksi untuk mengelola pesan masuk dan keluar. Secara default, SignalR membatasi buffer ini hingga 32 KB. Pesan terbesar yang dapat dikirim klien atau server adalah 32 KB. Memori maksimum yang digunakan oleh koneksi untuk pesan adalah 32 KB. Jika pesan Anda selalu lebih kecil dari 32 KB, Anda dapat mengurangi batas, yang:

  • Mencegah klien dapat mengirim pesan yang lebih besar.
  • Server tidak perlu mengalokasikan buffer besar untuk menerima pesan.

Jika pesan Anda lebih besar dari 32 KB, Anda dapat meningkatkan batas. Meningkatkan batas ini berarti:

  • Klien dapat menyebabkan server mengalokasikan buffer memori besar.
  • Alokasi server buffer besar dapat mengurangi jumlah koneksi bersamaan.

Ada batasan untuk pesan masuk dan keluar, keduanya dapat dikonfigurasi pada objek Http Koneksi ionDispatcherOptions yang dikonfigurasi di MapHub:

  • ApplicationMaxBufferSize mewakili jumlah maksimum byte dari klien yang di-buffer server. Jika klien mencoba mengirim pesan yang lebih besar dari batas ini, koneksi mungkin ditutup.
  • TransportMaxBufferSize mewakili jumlah maksimum byte yang dapat dikirim server. Jika server mencoba mengirim pesan (termasuk nilai pengembalian dari metode hub) yang lebih besar dari batas ini, pengecualian akan dilemparkan.

Mengatur batas untuk 0 menonaktifkan batas. Menghapus batas memungkinkan klien mengirim pesan dengan ukuran apa pun. Klien berbahaya yang mengirim pesan besar dapat menyebabkan kelebihan memori dialokasikan. Penggunaan memori berlebih dapat secara signifikan mengurangi jumlah koneksi bersamaan.

Artikel ini menyediakan informasi tentang mengamankan SignalR.

Berbagi Sumber Daya Lintas-Asal

Cross-Origin Resource Sharing (CORS) dapat digunakan untuk mengizinkan koneksi lintas asal SignalR di browser. Jika kode JavaScript dihosting di domain yang berbeda dari SignalR aplikasi, middleware CORS harus diaktifkan untuk memungkinkan JavaScript terhubung ke SignalR aplikasi. Izinkan permintaan lintas asal hanya dari domain yang Anda percayai atau kontrol. Misalnya:

  • Situs Anda dihosting di http://www.example.com
  • Aplikasi Anda SignalR dihosting di http://signalr.example.com

CORS harus dikonfigurasi di SignalR aplikasi untuk hanya mengizinkan asal www.example.com.

Untuk informasi selengkapnya tentang mengonfigurasi CORS, lihat Mengaktifkan Permintaan Lintas Asal (CORS). SignalR memerlukan kebijakan CORS berikut:

  • Izinkan asal spesifik yang diharapkan. Mengizinkan asal apa pun dimungkinkan tetapi tidak aman atau direkomendasikan.
  • Metode GET HTTP dan POST harus diizinkan.
  • Kredensial harus diizinkan agar cookiesesi lengket berbasis berfungsi dengan benar. Mereka harus diaktifkan bahkan ketika autentikasi tidak digunakan.

Namun, di 5.0 kami telah menyediakan opsi di klien TypeScript untuk tidak menggunakan kredensial. Opsi untuk tidak menggunakan kredensial hanya boleh digunakan saat Anda mengetahui 100% kredensial seperti Cookies tidak diperlukan di aplikasi Anda (cookiedigunakan oleh layanan aplikasi azure saat menggunakan beberapa server untuk sesi lengket).

Misalnya, kebijakan CORS berikut memungkinkan klien browser yang SignalR dihosting https://example.com untuk mengakses aplikasi yang SignalR dihosting di 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 ...
}

Pembatasan Asal WebSocket

Perlindungan yang diberikan oleh CORS tidak berlaku untuk WebSocket. Untuk pembatasan asal pada WebSocket, baca Pembatasan asal WebSockets.

Perlindungan yang diberikan oleh CORS tidak berlaku untuk WebSocket. Browser tidak:

  • Lakukan permintaan pra-penerbangan CORS.
  • Hormati batasan yang ditentukan dalam Access-Control header saat membuat permintaan WebSocket.

Namun, browser mengirim Origin header saat mengeluarkan permintaan WebSocket. Aplikasi harus dikonfigurasi untuk memvalidasi header ini untuk memastikan bahwa hanya WebSocket yang berasal dari asal yang diharapkan yang diizinkan.

Di ASP.NET Core 2.1 dan yang lebih baru, validasi header dapat dicapai menggunakan middleware kustom yang ditempatkan sebelum UseSignalR, dan middleware autentikasi di 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 ...
}

Catatan

Header Origin dikontrol oleh klien dan, seperti Referer header, dapat dipalsahkan. Header ini tidak boleh digunakan sebagai mekanisme autentikasi.

ConnectionId

Mengekspos ConnectionId dapat menyebabkan peniruan berbahaya jika SignalR server atau versi klien ASP.NET Core 2.2 atau yang lebih lama. SignalR Jika server dan versi klien ASP.NET Core 3.0 atau yang lebih baru, ConnectionToken bukan ConnectionId harus dirahasiakan. ConnectionToken tujuannya tidak diekspos di API apa pun. Mungkin sulit untuk memastikan bahwa klien yang lebih SignalR lama tidak terhubung ke server, jadi bahkan jika versi server Anda SignalR ASP.NET Core 3.0 atau yang lebih baru, ConnectionId seharusnya tidak diekspos.

Pengelogan token akses

Saat menggunakan WebSockets atau Server-Sent Events, klien browser mengirim token akses dalam string kueri. Menerima token akses melalui string kueri umumnya seaman menggunakan header standar Authorization . Selalu gunakan HTTPS untuk memastikan koneksi end-to-end yang aman antara klien dan server. Banyak server web mencatat URL untuk setiap permintaan, termasuk string kueri. Pengelogan URL dapat mencatat token akses. ASP.NET Core mencatat URL untuk setiap permintaan secara default, yang menyertakan string kueri. Misalnya:

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

Jika Anda memiliki kekhawatiran tentang pengelogan data ini dengan log server Anda, Anda dapat menonaktifkan pengelogan ini sepenuhnya dengan mengonfigurasi pencatat Microsoft.AspNetCore.Hosting ke Warning tingkat atau di atasnya (pesan ini ditulis pada Info tingkat). Untuk informasi selengkapnya, lihat Menerapkan aturan filter log dalam kode untuk informasi selengkapnya. Jika Anda masih ingin mencatat informasi permintaan tertentu, Anda dapat menulis middleware untuk mencatat data yang Anda butuhkan dan memfilter access_token nilai string kueri (jika ada).

Pengecualian

Pesan pengecualian umumnya dianggap sebagai data sensitif yang seharusnya tidak diungkapkan kepada klien. Secara default, SignalR tidak mengirim detail pengecualian yang dilemparkan oleh metode hub ke klien. Sebagai gantinya, klien menerima pesan generik yang menunjukkan terjadinya kesalahan. Pengiriman pesan pengecualian ke klien dapat ditimpa (misalnya dalam pengembangan atau pengujian) dengan EnableDetailedErrors. Pesan pengecualian tidak boleh diekspos ke klien di aplikasi produksi.

Manajemen buffer

SignalR menggunakan buffer per koneksi untuk mengelola pesan masuk dan keluar. Secara default, SignalR membatasi buffer ini hingga 32 KB. Pesan terbesar yang dapat dikirim klien atau server adalah 32 KB. Memori maksimum yang digunakan oleh koneksi untuk pesan adalah 32 KB. Jika pesan Anda selalu lebih kecil dari 32 KB, Anda dapat mengurangi batas, yang:

  • Mencegah klien dapat mengirim pesan yang lebih besar.
  • Server tidak perlu mengalokasikan buffer besar untuk menerima pesan.

Jika pesan Anda lebih besar dari 32 KB, Anda dapat meningkatkan batas. Meningkatkan batas ini berarti:

  • Klien dapat menyebabkan server mengalokasikan buffer memori besar.
  • Alokasi server buffer besar dapat mengurangi jumlah koneksi bersamaan.

Ada batasan untuk pesan masuk dan keluar, keduanya dapat dikonfigurasi pada objek Http Koneksi ionDispatcherOptions yang dikonfigurasi di MapHub:

  • ApplicationMaxBufferSize mewakili jumlah maksimum byte dari klien yang di-buffer server. Jika klien mencoba mengirim pesan yang lebih besar dari batas ini, koneksi mungkin ditutup.
  • TransportMaxBufferSize mewakili jumlah maksimum byte yang dapat dikirim server. Jika server mencoba mengirim pesan (termasuk nilai pengembalian dari metode hub) yang lebih besar dari batas ini, pengecualian akan dilemparkan.

Mengatur batas untuk 0 menonaktifkan batas. Menghapus batas memungkinkan klien mengirim pesan dengan ukuran apa pun. Klien berbahaya yang mengirim pesan besar dapat menyebabkan kelebihan memori dialokasikan. Penggunaan memori berlebih dapat secara signifikan mengurangi jumlah koneksi bersamaan.