我想使用WebSockets为我的应用程序进程间通信(Daemon<->WebGUI和Daemon<->FatClient等)。在测试期间，我尝试通过websocket.org (http://www.websocket.org/echo.html)上的JavaScript WebSocket客户端连接到本地运行的websocket服务器(ws://localhost:1234)。
我的问题是:
为什么这可能?是否在浏览器中没有实现跨域策略(这里:Linux上的FF29)?
我之所以问，是因为如果websocket.org是邪恶的，它可能会尝试与我的本地WS服务器通信，并将它从localhost收到的每条消息重定向到任何其他服务器:
<>之前本地WebSocket服务器浏览器邪恶的Web服务器在ws://localhost:1234 At http://evil.tld| | || |------[ 得到 /]---------& gt; || |& lt;——[HTML + EvilJS]——|| & lt;——[连接ws://. .]----| ||<----[一些交流]——>| || |----[邪恶前进]---->|| | |之前我还没有测试过整个用例，但是从websocket.org提供的JS连接到ws://localhost绝对有效。
要解决"为什么?"部分，浏览器不强制WebSockets同源策略(CORS是一种放松)，而不是AJAX调用，是因为WebSockets是在跨域请求的值建立之后引入的，因为它们一开始就不受SOP的约束，CORS客户端检查的历史原因不适用。
对于AJAX，在单一源策略的时代，服务器从不期望经过身份验证的浏览器从不同的域1发送请求，因此不需要确保请求来自受信任的位置2，只需检查会话cookie。后来的放松，如CORS，必须有客户端检查，以避免暴露现有的应用程序被滥用，违反这个假设(有效地进行CSRF攻击)。
如果Web是今天发明的，了解我们现在所知道的，那么AJAX既不需要SOP也不需要CORS，所有的验证都可能留给服务器。
WebSockets作为一项较新的技术，从一开始就被设计为支持跨域场景。任何编写服务器逻辑的人都应该意识到跨域请求的可能性，并执行必要的验证，而不需要严厉的浏览器端预防措施(如CORS)。
1这是一个简化。对资源的跨域GET请求(包括
2事实上，检查请求源的安全方法甚至不可用，因为Referer标头可以被欺骗，例如使用开放的重定向漏洞。这也显示了当时对CSRF漏洞的理解有多么贫乏。
oberstet回答了这个问题。谢谢你！不幸的是，我不能把它标记为"正确"，因为它是一个评论。浏览器发送"origin"报头，该报头可以被应用程序检查。
In Java [1]:
<>以前@Overridepublic void onOpen(WebSocket clientSocket, ClientHandshake握手){String clientOrigin = handshake.getFieldValue("origin");if (clientOrigin == null || !clientOrigin.equals(WEBSOCKET_ALLOWED_ORIGIN_HEADER)) {logger.log(水平。警告，"客户端没有发送正确的源报头:" + clientOrigin);clientSocket.close ();返回;}//……} 之前[1]使用https://github.com/TooTallNate/Java-WebSocket
WebSockets可以跨域通信，并且不受SOP(同源策略)的限制。
如果没有WebSockets，同样的安全问题也会发生。
邪恶的JS可以:
- 创建一个带有URL到evil的script/image标签。
- 创建表单标记，将数据放入字段中，并调用表单的"提交"动作，执行HTTP POST，可以跨域。AJAX受SOP的限制，而普通的HTTP POST则不受限制。查看XSRF web安全问题
如果有人在你的页面中注入javascript，或者你得到恶意的javascript，你的安全已经被打破了。