Pertimbangan keamanan di ASP.NET Core SignalR

Artikel ini menyediakan informasi tentang mengamankan SignalR.

Cross-Origin Resource Sharing (CORS) dapat digunakan untuk mengizinkan koneksi lintas-origin 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. Contohnya:

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

CORS harus dikonfigurasi dalam aplikasi SignalR agar 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 diaktifkan agar sesi sticky berbasis cookie 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 ketika Anda mengetahui 100% bahwa kredensial seperti cookie tidak diperlukan di aplikasi Anda (Cookie digunakan oleh layanan aplikasi Azure saat menggunakan beberapa server untuk sesi sticky).

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 CORS middleware: CORS dengan kebijakan bernama dan middleware.

Menerapkan kebijakan CORS ke SignalR titik akhir hub

Alih-alih menerapkan kebijakan CORS secara global dengan UseCors middleware, Anda dapat menerapkan CORS khusus ke SignalR titik akhir hub. Pendekatan ini memungkinkan kebijakan CORS yang berbeda untuk berbagai bagian aplikasi.

Ada dua cara untuk menerapkan kebijakan CORS ke SignalR hub: menautkan RequireCors pada pemetaan titik akhir, atau menambahkan [EnableCors] atribut ke kelas Hub. Kedua pendekatan memerlukan kebijakan CORS bernama untuk didaftarkan dalam konfigurasi layanan. Contoh berikut mendefinisikan kebijakan bernama "SignalRPolicy":

builder.Services.AddCors(options =>
{
    options.AddPolicy("SignalRPolicy", policy =>
    {
        policy.WithOrigins("https://example.com")
            .AllowAnyHeader()
            .WithMethods("GET", "POST")
            .AllowCredentials();
    });
});

Terapkan kebijakan CORS pada pemetaan titik akhir hub dengan menautkan RequireCorsMapHub pada panggilan:

app.MapHub<ChatHub>("/chatHub")
    .RequireCors("SignalRPolicy");

Terapkan kebijakan CORS pada kelas Hub dengan menambahkan [EnableCors] atribut :

[EnableCors("SignalRPolicy")]
public class ChatHub : Hub
{
    // ...
}

Untuk informasi selengkapnya tentang mengaktifkan CORS dengan perutean titik akhir, lihat Mengaktifkan CORS dengan perutean titik akhir.

Pembatasan Asal WebSocket

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

ConnectionId

Mengekspos ConnectionId dapat menyebabkan peniruan jahat jika server atau versi klien SignalR adalah ASP.NET Core 2.2 atau lebih lama. Jika versi server dan klien adalah ASP.NET Core 3.0 atau yang lebih baru, SignalR harus dirahasiakan, bukan ConnectionToken. ConnectionToken tidak diekspos secara sengaja di API mana pun. Mungkin sulit untuk memastikan bahwa klien yang lebih lama SignalR tidak terhubung ke server, jadi meskipun versi server Anda adalah 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. Contohnya:

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 diubah (misalnya dalam pengembangan atau pengujian) menggunakan 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 HttpConnectionDispatcherOptions 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 menjadi 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.

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

CORS harus dikonfigurasi dalam aplikasi SignalR agar 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 diaktifkan agar sesi sticky berbasis cookie berfungsi dengan benar. Mereka harus diaktifkan bahkan ketika autentikasi tidak digunakan.

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

Pembatasan Asal WebSocket

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

ConnectionId

Pengelogan token akses

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

Pengecualian

Manajemen buffer

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

Artikel ini menyediakan informasi tentang mengamankan SignalR.

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

CORS harus dikonfigurasi dalam aplikasi SignalR agar 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 diaktifkan agar sesi sticky berbasis cookie berfungsi dengan benar. Mereka harus diaktifkan bahkan ketika autentikasi tidak digunakan.

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

Pembatasan Asal WebSocket

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

ConnectionId

Pengelogan token akses

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

Pengecualian

Manajemen buffer

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

Artikel ini menyediakan informasi tentang mengamankan SignalR.

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

CORS harus dikonfigurasi dalam aplikasi SignalR agar 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 diaktifkan agar sesi sticky berbasis cookie berfungsi dengan benar. Mereka harus diaktifkan bahkan ketika autentikasi tidak digunakan.

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 WebSockets, 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 atau 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

Pengelogan token akses

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

Pengecualian

Manajemen buffer

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

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-07-06

Pertimbangan keamanan di ASP.NET Core SignalR

Berbagi Sumber Daya Lintas-Asal

Menerapkan kebijakan CORS ke SignalR titik akhir hub

Pembatasan Asal WebSocket

ConnectionId

Pengelogan token akses

Pengecualian

Manajemen buffer

Berbagi Sumber Daya Lintas-Asal

Pembatasan Asal WebSocket

ConnectionId

Pengelogan token akses

Pengecualian

Manajemen buffer

Berbagi Sumber Daya Lintas-Asal

Pembatasan Asal WebSocket

ConnectionId

Pengelogan token akses

Pengecualian

Manajemen buffer

Berbagi Sumber Daya Lintas-Asal

Pembatasan Asal WebSocket

ConnectionId

Pengelogan token akses

Pengecualian

Manajemen buffer

Saran dan Komentar

Sumber Daya Tambahan: