WebSocket is an HTML5 protocol that simplifies and speeds up communication between clients and servers. Once a connection is established through a handshake, messages can be passed back and forth while keeping the connection open.
For example, WebSocket connections are used for bi-directional, real-time applications such as support chats, news feeds, immediate quotes, or collaborative work. It is important to secure the content that is exchanged, otherwise an attacker could potentially gain access to the application server.
If your application uses WebSocket protocol, your security policy can protect WebSocket connections from exploits related to the protocol. If the policy uses automatic learning, the system handles much of the work for you. If you are using manual learning, you can add content profiles and WebSocket URLs to the security policy to protect WebSocket traffic.
This use case presumes that you have already created the security policy for the web application. It tells you what you need to do so that the system can recognize and secure WebSocket traffic.
Many web applications use two-way communication channels between the client and the server. The WebSocket Protocol, specified in RFC 6455, defines a way to speed up and simplify the communication.
Application Security Manager™ (ASM) provides security for WebSocket connections in security policies by adding WebSocket URLs (ws:// and wss://) and defining defense measures in a WebSocket profile. The WebSocket protocol allows extensions to add features to the basic framing protocol. The WebSocket URL informs ASM how to handle the extensions. The WebSocket URL also defines the allowed message format, size, and whether it is enforced.
You cannot associate parameters with WebSocket URLs. Therefore, any parameters in the request are handled at the global level.
WebSocket security can protect against many threats, including those listed in this table.
|Threat||How WebSocket Security Prevents It|
|Server stack abuse||Enforces mandatory headers in the request.|
|Session riding or CSRF||Denies access to requests coming from origins not in the configured whitelist.|
|Information leakage||Enforces login sessions for ws:// and wss:// URLs.|
|XSS, SQL injection, command shell injection, and other threats that attack signatures prevent||Uses attack signatures to examine parameter content in each WebSocket text message. If it finds them, closes the WebSocket connection and logs it in the Request log.|
|Server exploits||Examines text messages for RFC compliance, illegal meta characters, and null characters.|
|Cache poisoning||Enforces message masking for client text messages to avoid caching false content.|
|Buffer overflow||Limits message size, frame size, and enforces correct frame format. If messages are in JSON format, validates content.|
|Exhausted server socket resources||Limits the time for sending a message and time between messages.|
If your application uses login enforcement, you can specify authenticated WebSocket URLs that can only be accessed after login. To do this, the security policy needs to include at least one login page. You specify the WebSocket and WebSocket Secure (ws:// and wss://) URLs that must be authenticated on the login enforcement screen.
See Creating Login Pages for Secure Application Access for how to set up login enforcement for WebSocket URLs.
To prevent access to a WebSocket from an unauthorized origin, you can add more security to it. You can enable cross-domain request enforcement as part of the Allowed WebSocket URL properties within a security policy.
See Setting Up Cross-Domain Request Enforcement for how to set up cross-domain request enforcement for WebSocket URLs.
In Comprehensive policies, the system examines and classifies request content of learned WebSocket URLs, and creates a JSON profile if needed. The system stabilizes the security policy when sufficient sessions over a period of time include the same elements.
In Enhanced policies, the system learns URLs selectively, and classification is turned off, by default. Most WebSocket traffic is treated as plain text, and URLs with binary messages are learned (assuming they are the exception). The system does not learn JSON automatically because JSON is seen as plain text, and no violation is issued. If you want accurate automatic classification, you can change the policy type to Comprehensive, or turn on classification.
|Option||When you want to do this|
|Preserve||Preserve the mask of the packet received, and make no change. ASM and other modules receive masked frames.|
|Unmask||Remove the mask from the packet and remask it using the same mask when sending the traffic to the server. (Default value.)|
Preserve the mask of the packet received, and make no changes unless an Application Security Policy is associated with the virtual server. In that case, unmask the packet, allow ASM™ to examine the WebSocket payload, and remask it when sending the traffic to the server.
|Remask||Remove the mask received from the client. The system generates a new, random mask when sending the traffic to the server.|
|Enabled||Enforces the attack signature for this text profile, although the signature might be disabled for the policy in general. The system reports the violation Attack Signature Detected when the text in a request matches the attack signature.|
|Disabled||Disables the attack signature for this text profile, although the signature might be enabled in general.|
|Explicit||Specifies a specific WebSocket URL, such as /chat.room.com/websocket. Select WS (for unencrypted text) or WSS (for encrypted text), and type the URL in the adjacent field.|
|Wildcard||Specifies a wildcard expression to represent a number of URLs. Any URL that matches the wildcard expression is considered legal. The pure wildcard (*) is automatically added to the security policy so you do not need to add it. But you can add other wildcards such as /main/*. Select WS (for unencrypted text) or WSS (for encrypted text), and type a wildcard expression in the adjacent field.|
|Never (wildcard only)||Do not add explicit WebSocket URLs; just use a wildcard and relax the settings if it causes false positives.|
|Selective||Add explicit WebSocket URLs that do not match the attributes of the * wildcard.|
|Add All Entities||Add all WebSocket URLs used on the website.|
You can instruct the system to automatically examine and classify the content of requests to WebSocket URLs. If the system detects legitimate JSON, plain text, or binary data in requests to URLs allowed in the security policy, the system adds the content profiles to the security policy, and configures them using the data found.
This table lists the violations that Application Security Manager™ can detect in WebSocket traffic.
|Bad WebSocket handshake request||A problem occurred while establishing a WebSocket connection. The request did not comply with protocol.|
|Failure in WebSocket framing protocol||A framing protocol error occurred while parsing the message.|
|Illegal cross-origin request||The request did not come from the same origin as the traffic, and is not on the list of allowed origins in the HTTP or WebSocket URL.|
|Illegal number of frames per message||The request contains more frames than the WebSocket URL allows.|
|Illegal WebSocket binary message length||The binary message is longer than the WebSocket URL allows.|
|Illegal WebSocket extension||The message has an extension that the WebSocket URL does not allow.|
|Illegal WebSocket frame length||The message exceeds the maximum frame size permitted by the WebSocket URL.|
|Mask not found in client frame||The mask bit in the client frame is not set, and it needs to be.|
|Null character found in WebSocket text message||The system found a null character in a text message having has a content profile.|
|Text content found in binary only WebSocket||The WebSocket URL allows only binary content, but the message includes plain text.|