为什么没有WebSockets的同源策略？为什么我可以连接到ws:// localhost？
我想使用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的连接肯定有效。
回答 2
Stack Overflow用户
发布于 2018-03-26 08:59:09
。浏览器发送可由应用程序检查的“原始”标题。
在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;
}
// ...
}Stack Overflow用户
发布于 2018-03-26 10:24:08
“为什么？”
部分原因是，浏览器没有对WebSockets执行相同原点策略（其CORS放松）而不是AJAX调用，原因是WebSocket是在跨源请求的值建立之后引入的，并且因为它们不是受制于SOP，CORS客户端检查的历史原因不适用于他们。
最初，在AJAX调用的全局单一策略时代，服务器从未期望从不同的域接收到浏览器验证的请求，因此不需要检查Referer头以确保请求来自预期的源。后来，像CORS这样的放松必须进行客户端检查，以避免违反他们的假设来破坏现有的应用程序。
作为一项新技术，WebSockets旨在从一开始就支持跨域场景。任何编写服务器逻辑的人都应该意识到跨域请求的可能性，并执行必要的验证，而无需使用浏览器端强大的CORS预防措施。
https://stackoverflow.com/questions/-100007771
复制相似问题