WebSockets Origin Bypass 和 Cross-Site WebSocket Hijacking 的攻击原理和防御措施。 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位听众，早上好！今天咱们聊聊WebSocket安全里头的两个坑：WebSocket Origin Bypass 和 Cross-Site WebSocket Hijacking (CSWH)。别怕，听起来唬人，其实原理很简单，就像你家的门没锁好，坏人就能溜进来一样。我们不仅要了解他们怎么溜进来，还要知道怎么把门锁好，窗户钉死！

一、WebSocket Origin Bypass：你家的门牌号贴错了

首先，我们得知道WebSocket有个叫“Origin”的东西。这玩意儿就像你家的门牌号，告诉服务器：“嘿，我可是从example.com来的，不是隔壁老王家的evil.com！” 服务器一看门牌号对得上，就让你进。

1. 攻击原理：

Origin Bypass，顾名思义，就是绕过这个Origin检查。它通常发生在以下情况：

服务器配置错误： 服务器可能压根没检查Origin，或者检查方式有问题。比如，只检查了Origin是否存在，没检查Origin的值是否正确。
协议漏洞： 早期版本的WebSocket协议或者某些实现，可能存在绕过Origin检查的漏洞。
中间人攻击（Man-in-the-Middle）： 攻击者拦截了WebSocket握手请求，篡改了Origin头。

想象一下，你家门牌号随便贴个example.com，服务器也不仔细看，就让你进，这不就乱套了吗？

2. 代码示例（攻击）：

假设我们想伪装成example.com的客户端，连接到WebSocket服务器：

import websocket
import ssl

def on_message(ws, message):
    print(f"Received: {message}")

def on_error(ws, error):
    print(f"Error: {error}")

def on_close(ws, close_status_code, close_msg):
    print("### closed ###")

def on_open(ws):
    print("### opened ###")
    ws.send("Hello, Server! I'm from example.com (or am I?)")

if __name__ == "__main__":
    websocket.enableTrace(True)  # 开启调试信息，方便观察握手过程
    ws = websocket.WebSocketApp("wss://vulnerable-server.com/ws",  # 替换为你的目标WebSocket服务器地址
                                  on_open=on_open,
                                  on_message=on_message,
                                  on_error=on_error,
                                  on_close=on_close)

    #  关键：自定义Origin头
    ws.header = ["Origin: https://example.com"]

    ws.run_forever(sslopt={"cert_reqs": ssl.CERT_NONE})  # 忽略证书验证，方便测试

这段代码的关键在于ws.header = ["Origin: https://example.com"]。我们手动设置了Origin头，冒充是example.com来的。如果服务器没做好Origin检查，就会被我们骗过去。

3. 防御措施：

要防止Origin Bypass，服务器必须严格验证Origin头。

白名单机制： 只允许来自特定Origin的连接。

// Java (Spring WebSocket) 示例
@Override
public void configureHandshake(HandshakeWebSocketService service) {
    service.setAllowedOrigins("https://example.com", "https://another-safe-domain.com"); // 设置白名单
}

严格的Origin验证逻辑： 确保Origin头存在，并且值与期望值完全匹配。避免使用模糊匹配或者不区分大小写的比较。
使用最新的WebSocket协议和库： 及时更新WebSocket协议和库，修复已知的Origin Bypass漏洞。
安全审计： 定期进行安全审计，检查服务器配置是否存在Origin Bypass的风险。

二、Cross-Site WebSocket Hijacking (CSWH)：你家的钥匙被复制了

CSWH比Origin Bypass更阴险。它利用了浏览器的同源策略的漏洞，让恶意网站能够冒充用户建立WebSocket连接。

1. 攻击原理：

CSWH攻击依赖于以下几个条件：

用户已登录目标网站： 用户需要在目标网站（比如example.com）上登录，并且拥有有效的Session Cookie。
目标网站的WebSocket服务器没有正确处理CSRF： WebSocket服务器没有像传统的HTTP服务器那样，使用CSRF token来验证请求的合法性。
攻击者控制的恶意网站： 攻击者需要搭建一个恶意网站（比如evil.com），诱骗用户访问。

攻击过程是这样的：

用户登录example.com，浏览器保存了example.com的Session Cookie。
用户访问evil.com。
evil.com的恶意脚本通过JavaScript创建一个WebSocket连接，连接到example.com的WebSocket服务器。
由于浏览器会自动带上example.com的Session Cookie，WebSocket服务器误以为是用户发起的合法连接，允许连接建立。
evil.com的恶意脚本就可以通过WebSocket连接，冒充用户执行操作，比如窃取数据、发送恶意消息等。

这就像你家的钥匙被别人复制了，坏人拿着你的钥匙，就可以随便进你家门，为所欲为。

2. 代码示例（攻击）：

假设example.com的WebSocket服务器存在CSWH漏洞，攻击者可以编写以下恶意代码：

<!DOCTYPE html>
<html>
<head>
    <title>Evil Website</title>
</head>
<body>
    <h1>You've been PWNED!</h1>
    <script>
        //  替换为你的目标WebSocket服务器地址
        var ws = new WebSocket("wss://vulnerable-server.com/ws");

        ws.onopen = function() {
            console.log("WebSocket connection opened!");
            //  发送恶意消息，或者窃取数据
            ws.send("Give me all your secrets!");
        };

        ws.onmessage = function(event) {
            console.log("Received: " + event.data);
            //  处理服务器返回的数据，比如窃取敏感信息
        };

        ws.onclose = function() {
            console.log("WebSocket connection closed!");
        };

        ws.onerror = function(error) {
            console.error("WebSocket error: " + error);
        };
    </script>
</body>
</html>

这段代码非常简单，它在evil.com上创建一个WebSocket连接，连接到example.com的WebSocket服务器。由于浏览器会自动带上example.com的Session Cookie，如果服务器没有进行CSRF保护，就会被攻击者利用。

3. 防御措施：

CSWH的防御比Origin Bypass要复杂一些，需要综合考虑多个方面。

CSRF Token： 这是最有效的防御手段。服务器应该为每个WebSocket连接生成一个唯一的CSRF Token，并在客户端建立WebSocket连接时，将Token发送给服务器。服务器在处理WebSocket消息时，必须验证Token的有效性。

客户端代码 (JavaScript):

//  假设服务器返回了一个CSRF Token
var csrfToken = "YOUR_CSRF_TOKEN";

//  将CSRF Token作为子协议发送
var ws = new WebSocket("wss://vulnerable-server.com/ws", "csrf-token-" + csrfToken);

ws.onopen = function() {
    console.log("WebSocket connection opened with CSRF Token!");
    ws.send("Hello, Server!");
};

服务器端代码 (Java Spring WebSocket):

import org.springframework.web.socket.WebSocketSession;
import org.springframework.web.socket.handler.TextWebSocketHandler;

public class MyWebSocketHandler extends TextWebSocketHandler {

    @Override
    public void afterConnectionEstablished(WebSocketSession session) throws Exception {
        //  获取子协议
        String subProtocol = session.getAcceptedProtocol();

        //  验证CSRF Token
        if (subProtocol != null && subProtocol.startsWith("csrf-token-")) {
            String csrfToken = subProtocol.substring("csrf-token-".length());

            //  验证CSRF Token是否有效 (比如从数据库中查询)
            if (isValidCsrfToken(csrfToken)) {
                System.out.println("CSRF Token is valid!");
            } else {
                System.out.println("CSRF Token is invalid!");
                session.close(); // 关闭连接
            }
        } else {
            System.out.println("No CSRF Token provided!");
            session.close(); // 关闭连接
        }
    }

    private boolean isValidCsrfToken(String token) {
        //  TODO:  实现CSRF Token的验证逻辑
        //  比如从数据库中查询Token是否存在，是否过期等
        return true; //  替换为实际的验证逻辑
    }
}

双重验证 (Double Submit Cookie): 这是一种替代CSRF Token的方案。客户端在Cookie中保存一个随机值，同时在WebSocket消息中也包含这个随机值。服务器验证两个值是否一致。
SameSite Cookie属性： 将Session Cookie的SameSite属性设置为Strict或Lax。这可以防止浏览器在跨域请求中发送Session Cookie，从而减轻CSWH攻击的风险。
```
Set-Cookie: sessionid=YOUR_SESSION_ID; SameSite=Strict; Secure; HttpOnly
```
- Strict: 只有在同一站点发起的请求才会携带Cookie。
- Lax: 在某些跨站点请求中，浏览器可能会携带Cookie，比如点击链接或者通过GET方法提交表单。
Origin验证： 虽然Origin验证不能完全阻止CSWH攻击，但它可以作为一种额外的防御手段。确保只允许来自信任域名的WebSocket连接。
用户教育： 提醒用户不要随意点击不明链接，避免访问恶意网站。
Web Application Firewall (WAF)： 使用WAF可以检测和阻止恶意的WebSocket请求。

表格总结：

攻击类型	原理	防御措施
WebSocket Origin Bypass	服务器未正确验证Origin头，允许来自恶意域名的连接。	1. 白名单机制；2. 严格的Origin验证逻辑；3. 使用最新的WebSocket协议和库；4. 安全审计。
Cross-Site WebSocket Hijacking (CSWH)	恶意网站利用用户已登录的Session Cookie，冒充用户建立WebSocket连接。	1. CSRF Token；2. 双重验证 (Double Submit Cookie)；3. SameSite Cookie属性；4. Origin验证；5. 用户教育；6. Web Application Firewall (WAF)。

一些额外的思考：

子协议（Subprotocol）的使用： WebSocket支持子协议，可以在握手阶段协商使用的协议。这可以用于在服务器端验证客户端的身份，或者协商加密方式。
加固WebSocket通信： 使用WSS（WebSocket Secure）协议，对WebSocket通信进行加密，防止中间人攻击。
速率限制： 对WebSocket连接进行速率限制，防止恶意客户端发送大量请求。
监控和日志： 监控WebSocket连接，记录关键事件，以便及时发现和处理安全问题。

总而言之，WebSocket安全是一个需要重视的问题。我们需要了解常见的攻击手段，并采取相应的防御措施，才能确保WebSocket应用的安全性。就像装修房子一样，每个细节都要考虑到，才能住得安心，用得放心。

好了，今天的讲座就到这里。希望大家有所收获！如果有什么问题，欢迎提问。下次再见！

发表回复 取消回复

发表回复取消回复