WebSockets is an HTML5 feature that provides a full-duplex channel for a single TCP connection. Its continuous connection function makes it possible to build real-time applications in B/S mode. Websockets are often used in WEB applications with chat functions.
The following picture very closely illustrates the websockets used in an APT attack:
Same origin strategy ( Same origin policy): The same origin means that the domain name, protocol, and port are the same, that is, the browser will check different tabs of the same browser, and scripts with the same origin can be executed across tabs.
Origin field: The browser may add an Origin field when sending a POST request. This Origin field is mainly used to identify where the initial request was initiated. If the browser cannot determine where the origin is, the value of the Origin field in the request sent will be empty.
IronWASP: An open source WEB testing platform where users can customize security scans and define the plug-in system using python/ruby. For related introduction, see: //m.sbmmt.com/
ZAP (Zed Attack Proxy): It is a penetration testing framework that integrates various tools and can discover vulnerabilities in WEB applications. Related For an introduction, see: //m.sbmmt.com/
Recently, we conducted a security assessment on a WEB application with complex menu options and functions. Most operations in this application use web-sockets, which means that most of its actions will not be recorded in the http proxy log.
First, after we open the homepage, the website will load a static web page with JS scripts and CSS files. After that, the entire communication interaction will switch to Websockets mode, and a websocket connection will be established between the browser and the server to load all visible HTML resources in the website. When you click a link or submit a form, the browser will send some WebSocket messages to the server. After the server processes these messages, it will feedback through WebSocket, and then the client browser will display the new HTML content.
At this time, when websocket messages are interacting, the number of communications is very huge. There is an interaction of heartbeat detection packets between them every second. However, the existing tools did not meet my requirements, so I had to add a Websocket message analysis device and a WebSocket client to IronWASP so that it could identify Websockets and try to fuzz its vulnerabilities. You can learn more about it here.
While testing this application, I discovered that it has a WebSocket cross-site WebSocket Hijacking vulnerability (pioneered by Christian Schneider). Of course, I will explain the impact of this vulnerability before introducing the testing method to you. Before testing related Websockets applications, we need to make preparations first.
Everyone should understand that the Same Origin Policy (SOP) will not be enforced on websockets through the browser (under the same browser, pages protected by SSL , will not allow non-SSL WebSocket to pass). The application we tested uses http cookies as session authentication. The messages sent by WebSocket through the browser will not have Session ID or random parameters.
In this way, if a user logs in to a vulnerable WEB application and then opens //m.sbmmt.com/ (the attacker's website) in the same browser, http:/ /m.sbmmt.com/ can try to establish a WebSocket connection with the application's server through this vulnerable application, and then send a request packet with a valid authentication Session ID through the browser. Therefore, the WebSocket connection established by the attacker's website will have the same permissions as the application itself.
Since the entire application runs on websockets, hijacking WebSockets is equivalent to hijacking the user's session. So this vulnerability is essentially the same as a stored cross-site scripting vulnerability.
If you think this is bad, will you be more surprised when you hear that in some cases WebSocket cross-site scripting can even achieve remote code execution on the user's system? See the IPython Notebook example.
Before testing, the first thing you have to do is confirm whether WebSockets exists in the application. Fortunately, doing this is very simple. You only need to know the following three points:
1. WebSocket URL connections generally start with ws:// or wss://.
2. It is necessary to detect the Origin header of the established connection. The web page may be a WebSocket link established through the Origin field.
3. From the messages sent between the browser and the server, we can check the characteristics of ordinary WebSocket connections.
The following picture will show you: how to get the value of the Origin field and the URL value of WebSocket through the IronWASP log.
Once you have this information, you can use some special methods to detect cross-site WebSocket hijacking vulnerabilities. I will give three simple examples here:
It must be mentioned here that burpsuite can capture and record WebSockets messages. ZAP and IronWASP are the software that I know of that can replay websocket requests.
In burpsuite, we cannot replay websockets messages, but we can still detect whether the WebSocket handshake package is successful under limited conditions. For testing, we need to analyze the websocket upgrade request packets: they are sent over http or https and can therefore be replayed.
The following screenshot is the record of the burpsuite replayer (Repeat tab), which shows the effective request and response of the websocket connection:
For testing For this vulnerability, we need to send another request packet with a remade Origin header. If there is a "101 Web Socket Protocol Handshake" mark in our response packet, it means that the WebSocket has been successfully established.
If the connection is not established successfully, it means that the application does not have this vulnerability because it will reject external WebSocket connections. After the establishment is successful, we can start the next step of testing to see if the application has a WebSocket cross-site hijacking vulnerability. It needs to be explained here: Even if the connection has been established, it needs to be like a normal connection from Origin. Only after confirming that the server responds to the WebSocket message can the application be proved to be vulnerable. This is because developers may enable Origin detection and connection authority authentication at the same time. Therefore, the following situation may occur in our experiments: the established connection can be maintained forever, but Origins with external sources will not pass the authentication.
ZAP can replay WebSocket messages, but as far as I understand, it does not change the Origin header. The method introduced below can give you popular science on how to get more things through CSWSH (WebSocket cross-site hijacking).
Open the WEB application that needs to be tested and log in, then open a new tab in the same browser and visit http://www.php .cn/ (simulated hacker website), enter the URL address of the WebSocket, and then click the Connect button on the web page. Once the connection is established, you can send messages to the WebSocket server through this page. We need to replay the messages sent by the valid session and then check the server's response packet.
If the server's response is the same as the normal packet sent by the previous valid session, it means that the application may have a WebSocket cross-site hijacking vulnerability.
IronWASP provides automated scripts for even the most basic detections examine.
The server used in the above method of testing Origin is //m.sbmmt.com/, if you want to set the Origin value more flexibly , you can use IronWASP's client functionality. It allows you to customize the Origin value to test WebSocket connections.
Client functions may be used in the following circumstances:
1. The application allows WebSocket connections from open Origin
2. The application allows the Origin field value
from localhost and intranet IP. This approach is to facilitate developers and internal testing of applications. By using the IronWASP client, you can try whether the intranet IP or localhost as the Origin can take effect. If you can, then maybe you can use some tricks to exploit this vulnerability in a real environment. For example, if an application allows http://127.0.0.1:8080 as the Origin field, then we can do this: If the victim happens to have a WEB application running on the local port 8080, and it has a cross-site scripting vulnerability. If these conditions are met, the hacker can first conduct a cross-site attack on the WEB application, and then establish a WebSocket connection to the target application server:
If you need to use localhost or intranet IP to test the Origin header, using client scripts for automated detection will make your action easier. IronWASP allows you to implement custom scripting using Python or Ruby.
The following script can independently detect the intranet IP address filled in the Origin header and test whether the server recognizes it:
import clr
clr.AddReference("WebsocketClient.exe")
from WebsocketClient import *
def check_conn(origin):
print "Testing origin - " + origin
ws = SyncWebsockClient()
ws.Connect("ws://tatgetapp.com/ws", origin, "SessionID=KSDI2923EWE9DJSDS01212")
ws.Send("first message to send")
msg = ws.Read()
ws.Close()
if msg == "message that is part of valid session":
print "Connection successful!!"
return True
else:
return False
def check_nw():
for nws in ["192.168.0.0/16", "172.16.0.0/12", "10.0.0.0/8"]:
for ip in Tools.NwToIp(nws):
if check_conn("http://" + ip):
break
check_nw()
The above is the detailed content of Detailed introduction on how to fully control the Session? Let's look at the graphic and text code of WebSocket cross-site hijacking.. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
