EventSource/SSE(服务器发送事件)-安全 [英] EventSource / SSE (Server-Sent-Svents) - Security

问题描述

我已经阅读了w3规范@ http://www.w3.org/TR/eventsource /了解EventSource/SSE的工作原理，但是我找不到有关应如何创建私有流的任何好信息.

I have read through the w3 spec @ http://www.w3.org/TR/eventsource/ for how EventSource/SSE works, but I cant find any good information about how a private stream should be created.

基本上，我想创建一种将私有数据发送到特定用户会话的方法. 以下两种想法似乎都能满足我的要求，但我不确定它们的安全性.

Basically, I want to create a way to send private data to specific user-sessions. Both the ideas below seems to do what I want, but I am not so sure how secure they are.

示例；每个连接到相同EventSource URL的浏览器都会收到相同的数据，并且浏览器会跟踪所需的事件名称吗?

Example; does every browser connecting to the same EventSource URL receive the same data, and the browser keeps track of what event-name it wants?

var source = new EventSource('/stream');
source.addEventListener('l0ngr4nd0mSessionID', function(e){
    console.log('Received a private message:', e.data);
});

没有事件名称l0ngr4nd0mSessionID的任何人都可以得到此消息吗?

Will anyone without the event-name of l0ngr4nd0mSessionID be able to get this message?

这种情况如何?

var source = new EventSource('/stream/l0ngr4nd0mSessionID ');
source.addEventListener('private', function(e){
    console.log('Received a private message:', e.data);
});

这些示例与设置withCredentials选项一样好吗? 我的sse服务器与主Web服务器是一台单独的服务器，因此，我宁愿不使用withCredentials发送身份验证数据，而使用其中一个示例.

Is these examples just as good as setting the withCredentials option? My sse server is a seperate server than the main web-server, so I would prefeer to not send authentication-data using withCredentials and rather use one of the examples.

推荐答案

每个流都是私有的. SSE不是广播技术(除非您有意地实施它).而是为每个浏览器客户端提供了到服务器的专用套接字连接.您的服务器将使用并发事件处理程序来仅处理该客户端，并选择要发送给该客户端的信息.您也可以获取该客户的Cookie，因此可以识别其会话，并且基本身份验证也可以.

Each stream is private. SSE is not a broadcast technology (unless you deliberately implement it as such). Instead each browser client is given a dedicated socket connection to your server. Your server will use a concurrent event handler to deal with just that client, and will choose what information it wants to send to that client. You get that client's cookies too, so can identify their session, and basic authentication also works.

当涉及CORS时，一切都会变得更加复杂，即，如果您的SSE服务器的来源与从其提供HTML的来源不同.那就是你所描述的情况.您的服务器将必须发回"Access-Control-Allow-Origin: *"，但是如果您愿意发送该唯一的sessionID，则无需使用withCredentials.但是请注意，您将不会获得Cookie或基本身份验证数据.

Everything gets much more complex when CORS gets involved, i.e. if your SSE server is not the same origin as where the HTML was served from. That is the situation you described. Your server will have to send back "Access-Control-Allow-Origin: *", but you do not need to use withCredentials if you are happy to send that unique sessionID. But note that you will not get cookies or basic auth data.

回到您的问题，第一个例子很糟糕.这意味着您的服务器正在向所有客户端广播私有数据.除了隐私问题，这也是带宽的可怕浪费.

Going back to your question, the first example is bad. It implies your server is broadcasting private data to all clients. As well as the privacy issue, that is also a horrible waste of bandwidth.

您的第二种方法更好:您正在URL中使用某些内容来标识用户应接收的数据，而不是使用cookie或身份验证.请注意，任何知道此URL的人都可以获取相同的数据. SSL将无济于事.我猜您的会话ID是他们在登录到您的主网站时获得的，并且在他们注销时会过期.在大多数情况下，我认为这已经足够了:黑客必须为相当短的访问窗口付出很多麻烦.换句话说，更容易使用社交工程来获取用户的身份验证详细信息.但是您需要进行自己的风险/收益评估.

Your second approach is better: you are using something in the URL to identify the data the user should receive, in lieu of using a cookie or authentication. Note that anyone who knows this URL can get the same data. SSL will not help. I'm guessing your session ID is something that they get when logging in to your main web site, and that it expires when they log-out. For most situations I think this is Good Enough: a hacker has to go to quite a lot of trouble for a relatively short window of access. In other words it is easier to use social engineering to get the user's auth details. But you need to do your own risk/benefit evaluation.

最安全的方法是将SSL与cookie或基本身份验证一起使用.如果Web服务器和流服务器是相同的 origin ，这很容易；否则，您需要使用withCredentials.

The most secure approach is to use SSL with cookies or basic auth. This is easy if web server and streaming server are the same origin; otherwise you need to use withCredentials.

这篇关于EventSource/SSE(服务器发送事件)-安全的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！