为什么WebSockets没有同源策略？为什么我可以连接到ws：// localhost？

Question

我想将WebSockets用于我的应用程序的进程间通信（Daemon＆lt; - ＆gt; WebGUI和Daemon＆lt; - ＆gt; FatClient等）。在测试期间，我尝试通过websocket.org（http://www.websocket.org/echo.html）上的JavaScript WebSocket客户端连接到我本地运行的Web套接字服务器（ws：// localhost：1234）。

我现在的问题是：
为什么会这样？浏览器中是否没有实现跨源策略（这里是：Linux上的FF29）？

我在问，因为如果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肯定有效。

Answer 1

oberstet answered the question。谢谢！不幸的是，我无法将其标记为“正确”，因为它是一个评论。浏览器发送“origin”标题，可由应用程序检查。

在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 header: " + clientOrigin);        

        clientSocket.close();
        return;
    }

    // ...
}

[1]使用https://github.com/TooTallNate/Java-WebSocket

Answer 2

解决“为什么？”部分原因是浏览器不对WebSockets实施同源策略（其中CORS是一种放松）而不是AJAX调用，是因为WebSockets是在建立跨源请求的价值之后引入的，因为它们是'不受SOP约束，CORS客户端检查的历史原因不适用。

对于AJAX，在全面的单一来源策略的时代，服务器从未期望经过身份验证的浏览器从其他域 ¹ 发送请求，因此不需要确保请求是来自受信任的地点 ² 。后来像CORS这样的放松必须通过客户端检查来避免exposing existing applications to abuse违反这个假设（有效地做CSRF attack）。

如果今天发明了Web，知道我们现在知道的东西，那么AJAX就不需要SOP和CORS，所有的验证都可能留给服务器。

WebSockets是一种较新的技术，旨在从一开始就支持跨域方案。任何编写服务器逻辑的人都应该知道跨源请求的可能性并执行必要的验证，而不需要像CORS那样采用严厉的浏览器端预防措施。

¹ 这是一种简化。对源的跨源GET请求（包括＆lt; img＆gt;，＆lt; link＆gt;和＆lt; script＆gt;标记）和表单提交POST请求始终被允许作为Web的基本功能。如今，也允许其请求具有相同属性的跨源AJAX调用，并称为simple cross-origin requests。但是，除非服务器的CORS头明确允许，否则不允许从代码中的此类请求访问返回的数据。此外，正是这些“简单”的POST请求是服务器保护自己免受恶意网站攻击所必需的反CSRF令牌的主要原因。

² 实际上，检查请求源的安全方法甚至不可用，因为Referer标头可能是欺骗性的，例如使用开放式重定向漏洞。这也显示了当时对CSRF漏洞的理解程度。

Answer 3

WebSockets可以跨域通信，它们不受SOP（同源策略）的限制。

您所描述的相同安全问题可能在没有WebSockets的情况下发生。

邪恶的JS可以：

• 使用指向evil.tld的URL创建脚本/图像标记，并将数据放入查询字符串中。
• 创建表单标记，将数据放入字段中，然后调用表单的“提交”操作，执行HTTP POST，即可以跨域。 AJAX受SOP限制，但普通的HTTP POST不受限制。检查XSRF Web安全问题。

如果某些内容在您的网页中注入了javascript，或者您获得了恶意javascript，那么您的安全性已经被破坏。