websocket
The Same-Origin Policy (SOP) is one of the fundamental defences deployed in modern web applications. It restricts how a script from one origin can interact with the resources of a different origin. Last time, we talked about the Same-Origin Policy and how it protects a site’s data from unauthorized access:
同源策略(SOP)是现代Web应用程序中部署的基本防御措施之一。 它限制了一个来源的脚本如何与另一个来源的资源进行交互。 上次，我们讨论了“同源策略”及其如何保护站点数据免遭未经授权的访问：
However, there are some edge cases that the SOP does not cover, and these can often be exploited by attackers to steal private information. Today, we are going to talk about one of these edge cases: WebSocket connections, and how attackers can hijack WebSocket connections to leak private data. Let’s dive in!
但是，在某些极端情况下，SOP并没有涵盖这些情况，攻击者通常会利用这些情况来窃取私人信息。 今天，我们将讨论以下一种极端情况：WebSocket连接，以及攻击者如何劫持WebSocket连接以泄漏私有数据。 让我们潜入吧！
什么是WebSocket？ (What is WebSocket?)
WebSocket is, like HTTP, a communications protocol that enables interaction between a browser and a web server.
WebSocket与HTTP一样，是一种通信协议，可以在浏览器和Web服务器之间进行交互。
The WebSocket protocol allows both servers and browsers to send messages to each other using a single TCP connection. This is very useful when trying to create real-time applications such as online games and live chat. For example, Slack’s web app uses WebSocket connections to sync messages in its chat functionality.
WebSocket协议允许服务器和浏览器使用单个TCP连接相互发送消息。 在尝试创建实时应用程序(例如在线游戏和实时聊天)时，这非常有用。 例如，Slack的Web应用程序使用WebSocket连接在其聊天功能中同步消息。
In order for a web application to sync in real-time, web servers need to be able to actively push data to its clients. And this is where WebSocket comes in.
为了使Web应用程序实时同步，Web服务器需要能够主动将数据推送到其客户端。 这就是WebSocket的用武之地。
Traditionally, HTTP only supports client-initiated communications. This means that every time the real-time application needs to be synced (for example, an online game updating its live leaderboard), the client’s browser would need to send an HTTP request to retrieve the data from the server. When an application is constantly doing this type of update, this traditional method incurs a lot of unnecessary overhead and ultimately slows down the application.
传统上，HTTP仅支持客户端启动的通信。 这意味着每次需要同步实时应用程序(例如，更新其实时排行榜的在线游戏)时，客户端的浏览器就需要发送HTTP请求以从服务器检索数据。 当应用程序不断进行这种类型的更新时，这种传统方法会导致大量不必要的开销，并最终使应用程序变慢。
Whereas the WebSocket protocol solves this problem by creating a persistent connection between the client and the server that allows both client and server-initiated data transfers. During the lifetime of a WebSocket connection, the client and the server are free to exchange any amount of data without incurring the overhead and latency of using traditional HTTP requests.
而WebSocket协议通过在客户端和服务器之间创建持久连接来解决此问题，该持久连接允许客户端和服务器启动的数据传输。 在WebSocket连接的生存期内，客户端和服务器可以自由交换任何数量的数据，而不会产生使用传统HTTP请求的开销和延迟。
如何创建WebSocket连接 (How WebSocket connections are created)
A WebSocket connection between a client and a server is established through a WebSocket handshake.
客户端和服务器之间的WebSocket连接是通过WebSocket握手建立的。
This process is initiated by the client sending a normal HTTP or HTTPS request to the server with the special header: “Upgrade: websocket”. If the server supports WebSocket connections, it will respond with a 101 status code (Switching Protocols). From that point on, the handshake is complete and both parties are free to send data to the other.
客户端通过向服务器发送正常的HTTP或HTTPS请求 (带有特殊标头：“ Upgrade：websocket ”)来启动此过程。 如果服务器支持WebSocket连接，它将以101状态代码 (交换协议)进行响应。 从那时起，握手完成，双方可以自由地将数据发送给对方。
Side note: WebSocket uses the ws:// URL scheme, and the wss:// URL scheme for secure connections.
旁注：WebSocket使用 ws：// URL方案和 wss：// URL方案进行安全连接。
WebSocket的问题 (The problem with WebSocket)
As I mentioned in the Same-Origin Policy article, the SOP is a way of preventing unwanted data access from malicious domains. However, the Same-Origin Policy does not apply to WebSocket connections and modern browsers would not prevent data reads on a WebSocket connection across origins.
正如我在“同源策略”文章中提到的那样，SOP是一种防止来自恶意域的有害数据访问的方法。 但是，“同源策略”不适用于WebSocket连接，现代浏览器不会阻止跨源的WebSocket连接上的数据读取。
This means that if an attacker can create a WebSocket connection using a victim’s credentials, that connection would have the same access as a legitimate connection, regardless of where the connection is coming from.
这意味着，如果攻击者可以使用受害者的凭据创建WebSocket连接，则无论该连接来自何处，该连接都将具有与合法连接相同的访问权限。
跨站点WebSocket劫持(CSWSH) (Cross-Site WebSocket Hijacking (CSWSH))
A Cross-Site WebSocket Hijacking attack is essentially a CSRF on a WebSocket handshake.
跨站点WebSocket劫持攻击实质上是WebSocket握手上的CSRF 。
When a user is logged into victim.com in her browser and opens attacker.com in the same browser, attacker.com can try to establish a WebSocket connection to the server of victim.com. Since the user’s browser would automatically send over her credentials with any HTTP/ HTTPS request to victim.com, the WebSocket handshake request initiated by attacker.com would contain the user’s legitimate credentials. This means the resulting the WebSocket connection (created by attacker.com) would have the same level of access as if it originated from vicitm.com.
当用户登录到victim.com在她的浏览器，并在同一个浏览器中打开attacker.com，attacker.com可以尝试建立一个WebSocket连接到victim.com的服务器。 由于用户的浏览器会自动将她的凭证与任何HTTP / HTTPS请求victim.com送过来，由attacker.com发起WebSocket的握手请求将包含用户的合法凭证。 这意味着产生的WebSocket连接(通过attacker.com创建)将有机会获得相同的水平，如同它源自vicitm.com。
After the WebSocket connection is established, attacker.com can communicate directly to victim.com as a legitimate user.
WebSocket的连接建立后，可以attacker.com为合法用户直接通信，以victim.com。
攻击的结构 (Structure of an attack)
To carry out the attack, an attacker would create a script that will initiate the WebSocket connection to the victim server. She can then embed that script on a malicious page and trick a user into accessing the page.
为了进行攻击，攻击者将创建一个脚本，该脚本将启动与受害服务器的WebSocket连接。 然后，她可以将该脚本嵌入恶意页面，并诱骗用户访问该页面。
When the victim accesses the malicious page, her browser will automatically include her cookies into the WebSocket handshake request (since it’s a regular HTTP request). The malicious script crafted by the attacker will now have access to a WebSocket connection created using the victim’s credentials.
当受害者访问恶意页面时，其浏览器将自动将其cookie包含在WebSocket握手请求中(因为它是常规HTTP请求)。 攻击者制作的恶意脚本现在可以访问使用受害者的凭据创建的WebSocket连接。
跨站点WebSocket劫持的影响 (The impact of Cross-Site WebSocket Hijacking)
Using a hijacked WebSocket connection, the attacker can now achieve a lot of things:
通过使用劫持的WebSocket连接，攻击者现在可以实现很多事情：
WebSocket CSRF: If the WebSocket communication is used to carry out sensitive, state-changing actions, attackers can use this connection to forge actions on behalf of the user. For example, attackers can post fake messages onto a user’s chat groups.
WebSocket CSRF ：如果使用WebSocket通信执行敏感的状态更改操作，则攻击者可以使用此连接代表用户伪造操作。 例如，攻击者可以将虚假消息发布到用户的聊天组中。
Private data retrieval: If the WebSocket communication can be used to retrieve sensitive information via a client request, attackers can initiate fake requests to retrieve sensitive data belonging to the user.
私有数据检索 ：如果可以使用WebSocket通信通过客户端请求检索敏感信息，则攻击者可以发起虚假请求来检索属于用户的敏感数据。
Private data leaks via server messages: Attackers can also simply listen in on server messages and passively collect information leaked from these messages. For example, an attacker can use the connection to eavesdrop on a user’s incoming notifications.
通过服务器消息泄漏私人数据 ：攻击者还可以直接侦听服务器消息并被动收集从这些消息泄漏的信息。 例如，攻击者可以使用该连接窃听用户的传入通知。
如何防止跨站点WebSocket劫持 (How to prevent Cross-Site WebSocket Hijacking)
In order to prevent Cross-Site WebSocket Hijacking, an application would need to deny WebSocket handshake requests from unknown origins. There are two ways this can be achieved:
为了防止跨站点WebSocket劫持，应用程序将需要拒绝来自未知来源的WebSocket握手请求。 有两种方法可以实现：
Check the Origin header: browsers would automatically include an Origin header. This can be used to validate where the handshake request is coming from. When validating the Origin of the request, be sure to use a whitelist of URLs instead of a blacklist, and use a strict and rigorously tested regex expression.
检查Origin标头 ：浏览器将自动包含Origin标头。 这可以用来验证握手请求的来源。 验证请求的来源时，请确保使用URL的白名单而不是黑名单，并使用经过严格测试的正则表达式。
Use CSRF tokens for the WebSocket handshake request: applications could also use a randomized token on a WebSocket handshake request and validate it server-side before establishing a WebSocket connection. This way, if an attacker cannot leak or predict the random token, she will not be able to establish the connection.
将CSRF令牌用于WebSocket握手请求 ：应用程序还可以在WebSocket握手请求上使用随机令牌，并在建立WebSocket连接之前在服务器端对其进行验证。 这样，如果攻击者无法泄漏或预测随机令牌，则她将无法建立连接。
WebSocket is a big part of many modern applications. However, it is often overlooked as a potential attack vector.
WebSocket是许多现代应用程序的重要组成部分。 但是，它经常被视为潜在的攻击媒介。
It is important for developers and pentesters to be aware of this common pitfall and look out for these vulnerabilities before they are exploited in the wild.
对于开发人员和渗透测试者而言，重要的是要意识到这种常见的陷阱，并在野外利用这些漏洞之前要注意这些漏洞。
As always, thanks for reading!
一如既往，感谢您的阅读！
websocket
1264
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
