Using Socket.IO, to prevent client-side hijacking when sending JavaScript events - use SignalR?

Question

Using Socket.IO, clients are notified when other clients perform certain activities, through a JavaScript call to the Socket.IO server.

That message is broadcast to all clients, and client-side logic decides who sees the notification. (Another option for this is to maintain a collection of related clients on the server, and only send() to those clients - better?).

How would the system be built in order to prevent someone from hijacking the code and sending repeated notifications to the server? (some kind of tokenized send?) Simply using the session ID would not be sufficient, as someone could legitimately login, then use that session to try to bring the system down.

Rather than using JavaScript for this (avoiding the client-side hijacking possibility), another approach may be to use SignalR to send out the notifications from a code-behind scenario. Still researching this one, but some discussion/suggestions are welcome.

Thanks.

Answer 1

It is the one and only way to send messages only to those users that are allowed to read the message. If you don't do this, then absolutely nothing can guarantee you that this message won't be read buy a hacker.

As for the second question: what you are saying is that you want to protect against the DoS attack? Generally there is no solution for this. One thing you can do is to make server monitor what a given user emits and disconnect the user if he misbehaves (whatever that means :) ).

And what does client-side hijacking have to do with changing JavaScript to something else? If you send data to the client and then the client sends it back, then using JavaScript or not makes no difference for the hacker.

That's my advice for you.