Вопросы безопасности в ASP.NET Core SignalR

Статья
02/20/2024

В этой статье содержатся сведения о защите SignalR.

Совместное использование ресурсов между источниками (CORS) можно использовать для разрешения подключений между источниками SignalR в браузере. Если код JavaScript размещен в другом домене SignalR приложения, ПО промежуточного слоя CORS необходимо включить, чтобы разрешить JavaScript подключаться к SignalR приложению. Разрешить запросы между источниками только из доменов, которым вы доверяете или управляете. Например:

Сайт размещен в http://www.example.com
Приложение SignalR размещено в http://signalr.example.com

CORS следует настроить в SignalR приложении, чтобы разрешить только источник www.example.com.

Дополнительные сведения о настройке CORS см. в разделе "Включение запросов между источниками" (CORS). SignalRтребует следующих политик CORS:

Разрешить определенные ожидаемые источники. Разрешение любого источника возможно, но не является безопасным или рекомендуется.
Методы HTTP и POST должны быть разрешеныGET.
Учетные данные должны быть разрешены для cookieправильной работы сеансов на основе липких сеансов. Они должны быть включены, даже если проверка подлинности не используется.

Однако в версии 5.0 мы предоставили возможность в клиенте TypeScript не использовать учетные данные. Параметр не использовать учетные данные следует использовать только в том случае, если вы знаете 100 % о том, что учетные данные, такие как Cookies, не требуются в приложении (cookies используются службой приложений Azure при использовании нескольких серверов для липких сеансов).

Например, следующая выделенная политика CORS позволяет SignalR клиенту браузера, размещенного на https://example.com сайте, получить доступ к SignalR приложению, размещенном в 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");

В предыдущем примере политика CORS настраивается для разрешения определенных источников, методов и учетных данных. Дополнительные сведения о настройке политик CORS и ПО промежуточного слоя в ASP.NET Core см. в разделе ПО промежуточного слоя CORS: CORS с именованной политикой и ПО промежуточного слоя.

Ограничение происхождения WebSocket

Варианты защиты, предоставляемые CORS, не применяются к WebSocket. Для ограничения происхождения в WebSockets ознакомьтесь с ограничением источника WebSockets.

ConnectionId

Предоставление ConnectionId доступа может привести к злонамеренной олицетворении, если SignalR сервер или версия клиента ASP.NET Core 2.2 или более ранней версии. SignalR Если серверная и клиентская версия ASP.NET Core 3.0 или более поздней версии, то вместо ConnectionId того, ConnectionToken чтобы сохранить секрет. Он ConnectionToken намеренно не предоставляется в любом API. Это может быть трудно убедиться, что старые SignalR клиенты не подключаются к серверу, поэтому даже если SignalR версия сервера ASP.NET Core 3.0 или более поздней версии, ConnectionId не должна быть предоставлена.

Ведение журнала маркеров доступа

При использовании WebSockets или событий, отправленных сервером, клиент браузера отправляет маркер доступа в строке запроса. Получение маркера доступа через строку запроса обычно является безопасным, как и с помощью стандартного Authorization заголовка. Всегда используйте ПРОТОКОЛ HTTPS для обеспечения безопасного сквозного подключения между клиентом и сервером. Многие веб-серверы регистрируют URL-адрес для каждого запроса, включая строку запроса. Ведение журнала URL-адресов может заходить в журнал маркера доступа. ASP.NET Core регистрирует URL-адрес для каждого запроса по умолчанию, который включает строку запроса. Например:

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

Если у вас возникли проблемы с ведением журнала этих данных с помощью журналов сервера, вы можете полностью отключить это ведение журнала, настроив Microsoft.AspNetCore.Hosting средство ведения журнала на Warning уровень или выше (эти сообщения записываются на Info уровне). Дополнительные сведения см. в разделе "Применение правил фильтрации журналов" в коде для получения дополнительных сведений. Если вы по-прежнему хотите записать определенные сведения о запросе, можно написать по промежуточному слоям, чтобы записать необходимые данные и отфильтровать access_token значение строки запроса (при наличии).

Исключения

Сообщения об исключениях, как правило, считаются конфиденциальными данными, которые не следует раскрывать клиенту. По умолчанию SignalR не отправляет сведения об исключении, вызванном методом концентратора клиенту. Вместо этого клиент получает общее сообщение с указанием произошедшей ошибки. Доставку сообщений исключений клиенту можно переопределить (например, в разработке или тестировании) с помощью EnableDetailedErrors. Сообщения об исключениях не должны предоставляться клиенту в рабочих приложениях.

Управление буферами

SignalR использует буферы для каждого подключения для управления входящими и исходящими сообщениями. По умолчанию SignalR эти буферы ограничиваются 32 КБ. Наибольшее сообщение, которое может отправлять клиент или сервер, составляет 32 КБ. Максимальный объем памяти, потребляемой подключением для сообщений, составляет 32 КБ. Если ваши сообщения всегда меньше 32 КБ, можно уменьшить ограничение, которое:

Запрещает клиенту отправлять большее сообщение.
Сервер никогда не должен выделять большие буферы для приема сообщений.

Если ваши сообщения больше 32 КБ, можно увеличить ограничение. Увеличение этого ограничения означает:

Клиент может привести к тому, что сервер выделяет большие буферы памяти.
Выделение сервера больших буферов может уменьшить количество одновременных подключений.

Существуют ограничения для входящих и исходящих сообщений, которые можно настроить в объекте Http Подключение ionDispatcherOptions, настроенном вMapHub:

ApplicationMaxBufferSize представляет максимальное количество байтов от клиента, которое буферизирует сервер. Если клиент пытается отправить сообщение, превышающее это ограничение, подключение может быть закрыто.
TransportMaxBufferSize представляет максимальное количество байтов, которые сервер может отправлять. Если сервер пытается отправить сообщение (включая возвращаемые значения из методов концентратора), превышающий это ограничение, создается исключение.

Установка ограничения 0 для отключения ограничения. Удаление ограничения позволяет клиенту отправлять сообщение любого размера. Вредоносные клиенты, отправляя большие сообщения, могут привести к выделению избыточной памяти. Избыточное использование памяти может значительно сократить количество одновременных подключений.

В этой статье содержатся сведения о защите SignalR.

Сайт размещен в http://www.example.com
Приложение SignalR размещено в http://signalr.example.com

CORS следует настроить в SignalR приложении, чтобы разрешить только источник www.example.com.

Разрешить определенные ожидаемые источники. Разрешение любого источника возможно, но не является безопасным или рекомендуется.
Методы HTTP и POST должны быть разрешеныGET.
Учетные данные должны быть разрешены для cookieправильной работы сеансов на основе липких сеансов. Они должны быть включены, даже если проверка подлинности не используется.

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

Ограничение происхождения WebSocket

ConnectionId

Ведение журнала маркеров доступа

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

Исключения

Управление буферами

Запрещает клиенту отправлять большее сообщение.
Сервер никогда не должен выделять большие буферы для приема сообщений.

Если ваши сообщения больше 32 КБ, можно увеличить ограничение. Увеличение этого ограничения означает:

Клиент может привести к тому, что сервер выделяет большие буферы памяти.
Выделение сервера больших буферов может уменьшить количество одновременных подключений.

ApplicationMaxBufferSize представляет максимальное количество байтов от клиента, которое буферизирует сервер. Если клиент пытается отправить сообщение, превышающее это ограничение, подключение может быть закрыто.
TransportMaxBufferSize представляет максимальное количество байтов, которые сервер может отправлять. Если сервер пытается отправить сообщение (включая возвращаемые значения из методов концентратора), превышающий это ограничение, создается исключение.

В этой статье содержатся сведения о защите SignalR.

Сайт размещен в http://www.example.com
Приложение SignalR размещено в http://signalr.example.com

CORS следует настроить в SignalR приложении, чтобы разрешить только источник www.example.com.

Разрешить определенные ожидаемые источники. Разрешение любого источника возможно, но не является безопасным или рекомендуется.
Методы HTTP и POST должны быть разрешеныGET.
Учетные данные должны быть разрешены для cookieправильной работы сеансов на основе липких сеансов. Они должны быть включены, даже если проверка подлинности не используется.

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

Ограничение происхождения WebSocket

ConnectionId

Ведение журнала маркеров доступа

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

Исключения

Управление буферами

Запрещает клиенту отправлять большее сообщение.
Сервер никогда не должен выделять большие буферы для приема сообщений.

Если ваши сообщения больше 32 КБ, можно увеличить ограничение. Увеличение этого ограничения означает:

Клиент может привести к тому, что сервер выделяет большие буферы памяти.
Выделение сервера больших буферов может уменьшить количество одновременных подключений.

ApplicationMaxBufferSize представляет максимальное количество байтов от клиента, которое буферизирует сервер. Если клиент пытается отправить сообщение, превышающее это ограничение, подключение может быть закрыто.
TransportMaxBufferSize представляет максимальное количество байтов, которые сервер может отправлять. Если сервер пытается отправить сообщение (включая возвращаемые значения из методов концентратора), превышающий это ограничение, создается исключение.

В этой статье содержатся сведения о защите SignalR.

Сайт размещен в http://www.example.com
Приложение SignalR размещено в http://signalr.example.com

CORS следует настроить в SignalR приложении, чтобы разрешить только источник www.example.com.

Разрешить определенные ожидаемые источники. Разрешение любого источника возможно, но не является безопасным или рекомендуется.
Методы HTTP и POST должны быть разрешеныGET.
Учетные данные должны быть разрешены для cookieправильной работы сеансов на основе липких сеансов. Они должны быть включены, даже если проверка подлинности не используется.

Например, следующая политика CORS позволяет SignalR клиенту браузера, размещенного на https://example.com сайте, получить доступ к SignalR приложению, размещенного в 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 ...
}

Ограничение происхождения WebSocket

Варианты защиты, предоставляемые CORS, не применяются к WebSocket. Браузеры не поддерживают следующие задачи:

выполнение предварительных запросов CORS;
использование ограничений, указанных в заголовках Access-Control, при выполнении запросов WebSocket.

Однако браузеры отправляют заголовок Origin при выпуске запросов WebSocket. Приложения должны быть настроены для проверки этих заголовков, чтобы использовались только WebSocket из ожидаемых источников.

В ASP.NET Core 2.1 и более поздних версий можно выполнить проверку заголовка с помощью пользовательского ПО промежуточного слоя, размещенного до UseSignalR, и по промежуточного слоя проверки подлинности в 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 ...
}

Примечание.

Заголовок Origin контролируется клиентом и, как и заголовок Referer, может быть подделан. Эти заголовки не должны использоваться в качестве механизма проверки подлинности.

ConnectionId

Ведение журнала маркеров доступа

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

Исключения

Управление буферами

Запрещает клиенту отправлять большее сообщение.
Сервер никогда не должен выделять большие буферы для приема сообщений.

Если ваши сообщения больше 32 КБ, можно увеличить ограничение. Увеличение этого ограничения означает:

Клиент может привести к тому, что сервер выделяет большие буферы памяти.
Выделение сервера больших буферов может уменьшить количество одновременных подключений.

ApplicationMaxBufferSize представляет максимальное количество байтов от клиента, которое буферизирует сервер. Если клиент пытается отправить сообщение, превышающее это ограничение, подключение может быть закрыто.
TransportMaxBufferSize представляет максимальное количество байтов, которые сервер может отправлять. Если сервер пытается отправить сообщение (включая возвращаемые значения из методов концентратора), превышающий это ограничение, создается исключение.

Вопросы безопасности в ASP.NET Core SignalR

Ограничение происхождения WebSocket

ConnectionId

Ведение журнала маркеров доступа

Исключения

Управление буферами

Ограничение происхождения WebSocket

ConnectionId

Ведение журнала маркеров доступа

Исключения

Управление буферами

Ограничение происхождения WebSocket

ConnectionId

Ведение журнала маркеров доступа

Исключения

Управление буферами

Ограничение происхождения WebSocket

ConnectionId

Ведение журнала маркеров доступа

Исключения

Управление буферами

Обратная связь

Дополнительные ресурсы

Вопросы безопасности в ASP.NET Core SignalR

Общий доступ к ресурсам независимо от источник

Ограничение происхождения WebSocket

ConnectionId

Ведение журнала маркеров доступа

Исключения

Управление буферами

Общий доступ к ресурсам независимо от источник

Ограничение происхождения WebSocket

ConnectionId

Ведение журнала маркеров доступа

Исключения

Управление буферами

Общий доступ к ресурсам независимо от источник

Ограничение происхождения WebSocket

ConnectionId

Ведение журнала маркеров доступа

Исключения

Управление буферами

Общий доступ к ресурсам независимо от источник

Ограничение происхождения WebSocket

ConnectionId

Ведение журнала маркеров доступа

Исключения

Управление буферами

Обратная связь

Дополнительные ресурсы