为什么没有WebSockets的同源策略?为什么我可以连接到ws:// localhost?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (50)

我想使用WebSocket为我的应用程序(Daemon<->WebGui和Daemon<->FatClient等)进行进程间通信。在测试期间,我尝试通过websocket.org上的JavaScriptWebSocket客户端连接到本地运行的web套接字服务器(ws://localhost:1234)

我现在的问题是:

为什么这是可能的?浏览器中是否没有实现跨源策略?

我之所以这样问是因为如果websocket.org是坏的,它可以尝试与我的本地WS服务器进行通信,并将从localhost接收到的每一条消息重定向到任何其他服务器:

Local WebSocket Server            Browser            Evil Web Server
at ws://localhost:1234                               at http://evil.tld
        |                            |                       |
        |                            |------[GET /]--------->|
        |                            |<-----[HTML+EvilJS]----|
        |<------[connect ws://..]----|                       |
        |<----[some communication]-->|                       |
        |                            |----[evil forward]---->|
        |                            |                       |

我还没有测试整个用例,但是websocket.org提供的JS中的ws://localhost的连接肯定有效。

提问于
用户回答回答于

。浏览器发送可由应用程序检查的“原始”标题。

在Java [1]中:

@override
public void onOpen(WebSocket clientSocket,ClientHandshake handshake){
    string clientOrigin = handshake.getFieldValue(“origin”);

    if(clientOrigin == null ||!clientOrigin.equals(WEBSOCKET_ALLOWED_ORIGIN_HEADER)){
        logger.log(Level.WARNING,“Client did not sent correct origin:”+ clientOrigin);        

        clientSocket.close();
        return;
    }

    // ...
}

用户回答回答于

“为什么?”

部分原因是,浏览器没有对WebSockets执行相同原点策略(其CORS放松)而不是AJAX调用,原因是WebSocket是在跨源请求的值建立之后引入的,并且因为它们不是受制于SOP,CORS客户端检查的历史原因不适用于他们。

最初,在AJAX调用的全局单一策略时代,服务器从未期望从不同的域接收到浏览器验证的请求,因此不需要检查Referer头以确保请求来自预期的源。后来,像CORS这样的放松必须进行客户端检查,以避免违反他们的假设来破坏现有的应用程序。

作为一项新技术,WebSockets旨在从一开始就支持跨域场景。任何编写服务器逻辑的人都应该意识到跨域请求的可能性,并执行必要的验证,而无需使用浏览器端强大的CORS预防措施。

扫码关注云+社区