Shulou(Shulou.com)05/31 Report--

This article mainly shows you the "sample analysis of WebSockets security vulnerabilities", which is easy to understand and well-organized. I hope it can help you solve your doubts. Let the editor lead you to study and learn the article "sample Analysis of WebSockets Security vulnerabilities".

1. WebSockets

WebSockets is widely used in modern Web applications. They are initiated through HTTP and provide long-term connectivity through two-way communication.

WebSocket is used for a variety of purposes, including performing user operations and transmitting sensitive information. Almost any Web security vulnerability that occurs with regular HTTP may also be related to WebSockets traffic.

2. What's the difference between HTTP and WebSockets?

Most of the communication between Web browsers and Web sites uses HTTP. Using HTTP, the client sends a request and the server returns a response. Typically, the response occurs immediately and the transaction completes. Even if the network connection remains open, this will be used for separate transactions for requests and responses.

Some modern websites use WebSockets. WebSocket connections are initiated through HTTP and are usually long-standing. Messages can be sent in either direction at any time and are not transactional in nature. The connection usually remains open and idle until the client or server is ready to send a message.

WebSocket is especially useful when low latency or server startup messages are needed, such as real-time feeds of financial data.

3. How do I establish a WebSocket connection?

WebSocket connections are typically created using client-side JavaScript, as follows:

Var ws = new WebSocket ("wss://normal-website.com/chat")

Be careful

The wss protocol is built on the WebSocket of an encrypted TLS connection, while the ws protocol uses an unencrypted connection.

To establish a connection, the browser and server perform a WebSocket handshake via HTTP. The browser issues a WebSocket handshake request, as shown below:

GET / chat HTTP/1.1Host: normal-website.comSec-WebSocket-Version: 13Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==Connection: keep-alive, UpgradeCookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2Upgrade: websocket

If the server accepts the connection, it returns a WebSocket handshake response, as shown below:

HTTP/1.1 101NIf Switching ProtocolsConnection: UpgradeUpgrade: websocketSec-WebSocket-Accept: 0FFPcards 2nmNIf

At this point, the network connection remains open and can be used to send WebSocket messages to either direction.

Be careful

Several functions of the WebSocket handshake message are worth noting:

The Connection and Upgrade headers in the request and response indicate that this is an WebSocket handshake.

The Sec-WebSocket-Version of the request header specifies the WebSocket protocol version that the client wants to use. It's usually like this 13.

The Sec-WebSocket-Key of the request header contains a random value encoded by Base64, which should be generated randomly at each handshake request.

The Sec-WebSocket-Accept of the response header is contained in the hash Sec-WebSocket-Key request header of the submitted value, with a specific string concatenation defined in the protocol specification. This is done to prevent misleading responses due to server configuration errors or proxy caching errors.

4. What is the WebSocket message like?

After an WebSocket connection is established, the client or server can send messages asynchronously in either direction.

You can use the client-side JavaScript to send a simple message from the browser, as follows:

Ws.send ("Peter Wiener")

In principle, WebSocket messages can contain any content or data format. In modern applications, JSON is often used to send structured data in WebSocket messages.

For example, a chat robot application that uses WebSockets might send a message like this:

{"user": "Hal Pline", "content": "I wanted to be a Playstation growing up, not a device to answer your inane questions"} 5. WebSockets security vulnerabilities

In principle, virtually any Web security vulnerability related to WebSockets can occur:

User-supplied input transferred to the server may be processed in an insecure manner, resulting in vulnerabilities such as SQL injection or XML external entity injection.

Some blind vulnerabilities achieved through WebSockets may only be detected using out-of-band (OAST) technology.

If data controlled by an attacker is transferred to other application users through WebSockets, it may lead to XSS or other client vulnerabilities.

5.1 processing of WebSocket messages to exploit vulnerabilities

Most input-based vulnerabilities that affect WebSocket can be discovered and exploited by tampering with the contents of WebSocket messages.

For example, suppose a chat application uses WebSockets to send chat messages between the browser and the server. When a user types a chat message, a WebSocket message like the following is sent to the server:

{"message": "Hello Carlos"}

The contents of the message (again via WebSockets) are transferred to another chat user and rendered in the user's browser, as shown below:

Hello Carlos

In this case, an attacker can perform a proof-of-concept XSS attack by submitting the following WebSocket message, as long as there is no other input processing or defense at work:

{"message": "

"}

Shooting range url: https://portswigger.net/web-security/websockets/lab-manipulating-messages-to-exploit-vulnerabilities

Details of reappearance:

There is a real-time chat feature on the home page, and the dialog box is directly inserted into xss to grab and modify the package:

Modified to:

You can see that the payload has been successfully inserted:

Success pop-up window:

5.2 manipulating WebSocket handshakes to exploit vulnerabilities

Certain WebSocket vulnerabilities can only be discovered and exploited by manipulating the WebSocket handshake. These vulnerabilities often involve design flaws, such as:

Misplaced trust in HTTP headers to make security decisions, such as X-Forwarded-For headers.

The session handling mechanism is flawed because the session context for processing WebSocket messages is usually determined by the session context of the handshake message.

The attack surface introduced by the custom HTTP header used by the application.

Target aircraft url: https://portswigger.net/web-security/websockets/lab-manipulating-handshake-to-exploit-vulnerabilities

Details of reappearance:

Similarly, insert xss directly into the real-time chat dialog and observe that the attack has been blocked and the WebSocket connection has been terminated. After reloading, it is observed that the connection attempt failed because the IP address has been disabled.

Re-request and grab the package, modify the request header, and add xff:

You can reconnect to WebSocket and try a valid xss:

Success pop-up window:

5.3 exploit vulnerabilities using cross-site WebSocket

Some WebSockets security vulnerabilities occur when an attacker establishes a cross-domain WebSocket connection from an attacker-controlled website. This is called a cross-site WebSocket hijacking attack and involves exploiting a cross-site request forgery (CSRF) vulnerability in the WebSocket handshake. Attacks often have a serious impact, allowing the attacker to perform privileged operations on behalf of the victim user or capture sensitive data that the victim user can access.

5.3.1 what is cross-site WebSocket hijacking?

Cross-site WebSocket hijacking (also known as cross-domain WebSocket hijacking) involves a cross-site request forgery (CSRF) vulnerability in the WebSocket handshake. This occurs when the WebSocket handshake request relies solely on HTTP cookie for session processing and does not contain any CSRF tokens or other unpredictable values.

Attackers can create malicious web pages on their domain to establish cross-site WebSocket connections to vulnerable applications. The application will handle the connection in the context of the victim's session with the application.

The attacker's page can then send any message to the server over the connection and read the contents of the message received from the server. This means that, unlike regular CSRF, attackers can interact with infected applications in both directions.

5.3.2 what is the impact of cross-site WebSocket hijacking?

A successful cross-site WebSocket hijacking attack usually enables an attacker to:

Perform an unauthorized operation disguised as a victim user. As with regular CSRF, attackers can send arbitrary messages to server-side applications. If the application performs any sensitive operations using WebSocket messages generated by the client, the attacker can generate appropriate messages across domains and trigger these actions.

Retrieve sensitive data that users can access. Unlike regular CSRF, cross-site WebSocket hijacking allows attackers to interact with vulnerable applications in both directions through the hijacked WebSocket. If the application uses WebSocket messages generated by the server to return any sensitive data to the user, an attacker can intercept those messages and capture the data of the victim user.

5.3.3 perform a cross-site WebSocket hijacking attack

Because the cross-site WebSocket hijacking attack is essentially a CSRF vulnerability in the WebSocket handshake, the first step in performing the attack is to check the WebSocket handshake performed by the application and determine if CSRF is protected.

In the normal case of a CSRF attack, you usually need to look for handshake messages that rely only on HTTP cookie for session processing and do not use any tokens or other unpredictable values in the request parameters.

For example, the following WebSocket handshake request may be vulnerable to CSRF attacks because the only session token is transmitted in cookie:

GET / chat HTTP/1.1Host: normal-website.comSec-WebSocket-Version: 13Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==Connection: keep-alive, UpgradeCookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2Upgrade: websocket attention

The Sec-WebSocket-Key header contains a random value to prevent errors from caching agents, rather than for authentication or session processing purposes.

If the WebSocket handshake request is vulnerable to CSRF, the attacker's web page can perform a cross-site request to open the WebSocket on the vulnerable site. The next step in the attack will depend entirely on the logic of the application and how it uses WebSockets. The attack may involve:

Send a WebSocket message to perform unauthorized actions on behalf of the victim user.

Send WebSocket messages to retrieve sensitive data.

Sometimes you just wait for an incoming message that contains sensitive data to arrive.

6. How to secure a WebSocket connection

To minimize the risk of security vulnerabilities caused by WebSocket, use the following guidelines:

Use the wss:// protocol (TLS-based WebSockets).

Hard-code the URL of the WebSockets endpoint, of course, do not merge user-controllable data into this URL.

Protect WebSocket handshake messages from CSRF attacks to avoid cross-site WebSocket hijacking vulnerabilities.

Data received through WebSocket is considered untrusted in both directions. Securely process data on the server and client to prevent input-based vulnerabilities such as SQL injection and cross-site scripting.

The above is all the contents of the article "sample Analysis of WebSockets Security vulnerabilities". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.