Introduction To Preservation Used in ASP.Net SignalR

Introduction

This article is an introduction to ASP.NET SignalR Security. There are various types of security concerns that are important to be considered during application development of ASP.NET SignalR applications. I have also described SignalR in MVC 5 to understand the SignalR methodology.

So, let's proceed with the following sections to understand the security in SignalR:

• Security Approach
  
  • Authentication and authorization
  • Connection token
  • Group Rejoining
• Restrict Cross-Site Request Forgery
• Security Instructions
  
  • SSL Protocol
  • Client Input Handling
  • Auto generated JavaScript proxy files
  • Exceptions

Security Approach

The following are some security approaches of SignalR that should be used in applications

Authentication and authorization

There are no features for user authentication provided by SignalR. Instead of that, you need to integrate the feature of SignalR into the existing authentication structure for an application. In this it will work normally as user authenticate in the application and work with the results of the authentication in the SignalR code. For an example, you can use forms authentication to users authentication and then in the hub, enforce that your users or roles are authorized to call the method. You can also pass user authentication information to the client.

The Authorize attribute of SignalR specifies which users have the access to a hub or method. It is applied to either a hub or method. If this attribute is not applied, then all public methods of the hub are accessible from the client that is connected to the hub. This attribute is applied to hubs but not persistence connections.

Connection token

The client and server both pass a connection token in which the authenticated user connection id and user name are stored. The connection id identifies the connected client uniquely. When a new connection is created, the server generates the connection id randomly and persists the id for the duration of the connection. SignalR uses encryption and a digital signature to secure the connection token.

The Server has the responsibility to check the contents of each token to ensure that the request is coming from the specified user. The username is generated with the corresponding connection id. By validating the connection id and username, SignalR prohibits the petty user from easily impersonating another user. The request fails if the server does not validate the connection token.

Group Rejoining

This section describes the groups rejoining when reconnecting. The user is automatically re-assigned to the appropriate group by the SignalR app as a default when reconnecting from a temporary disruption. The client passes a group token that contains the id and assigned group while reconnecting. The group token is digitally signed and encrypted. The group token does not expire. For managing the user association to their group securely, you need to store the data on the server as in a database. We need to provide logic to verify whether or not a user belongs to the group. The automatic group rejoining is only applied when a connection is re-connected after a temporary disruption.

Restrict Cross-Site Request Forgery

The Cross-Site Request Forgery (CSRF) is an attack where a petty site sends a request to a vulnerable site where the user is currently logged in. Let's see how this attack is possible using the following:

• A user is logged into www.xyz123.com by forms authentication
• The server authenticates the user.
• Now the user visits a malicious site without logging out, but in the logged form the action method is posted and the user is visiting to a malicious site. It is part of CSRF.

SignalR takes the following steps to prevent a malicious site from creating a valid request:

• Disable cross domain request
  
  The cross domain request is disabled by SignalR to avoid users from calling a SignalR endpoint from an external domain. The request is considered as an invalid request and blocked.
  
• Token passed to query string, not cookie
  
  SignalR passes the token to the query string instead of the cookie. It is unsafe to store the connection in the cookie because the browser can forward the connection token carelessly when the malicious code is encountered.
  
• Connection token verification
  
  The connection id must match the username otherwise it is not processed by the server. The connection id becomes invalid as soon as the connection is ended. Unnamed users should not have access to any essential information.

Security Instructions

There are some security instructions to be followed that are given below:

SSL Protocol

The Secure Socket Protocol uses encryption to secure the data transaction between the client and the server. It is necessary to use SSL, if the SignalR app sends the essential info between the client and the server.

Client Input Handling

You must encode the inputs from clients that discuss with the other clients to ensure that a nasty user does not send the script to another user. You should also encode the message on the receiving clients rather then the server because it is also possible that the SignalR app have different clients. So, HTML encoding works for a web client but not for others.

For an example:

var chat = $.connection.chatHub;