Использование Socket.IO для предотвращения захвата на стороне клиента при отправке событий JavaScript — используйте SignalR?

Используя Socket.IO, клиенты уведомляются, когда другие клиенты выполняют определенные действия, посредством вызова JavaScript к серверу Socket.IO.

Это сообщение рассылается всем клиентам, и логика на стороне клиента решает, кто увидит уведомление. (Другой вариант для этого — поддерживать коллекцию связанных клиентов на сервере, и только send() этим клиентам — лучше?).

Как должна быть построена система, чтобы предотвратить взлом кода и повторную отправку уведомлений на сервер? (какая-то токенизированная отправка?) Простого использования идентификатора сеанса будет недостаточно, поскольку кто-то может законно войти в систему, а затем использовать этот сеанс, чтобы попытаться вывести систему из строя.

Вместо того, чтобы использовать для этого JavaScript (избегая возможности перехвата на стороне клиента), другим подходом может быть использование SignalR для отправки уведомлений из сценария с выделенным кодом. Все еще исследую этот вопрос, но некоторые обсуждения/предложения приветствуются.


javascript socket.io signalr dom-events session-hijacking
person ElHaix    schedule 05.03.2012    source источник
comment
К сожалению, у меня нет ответа, но я буду ждать его. +1 за хороший вопрос!   -  person francisco.preller    schedule 06.03.2012

Ответы (1)


arrow_upward
0
arrow_downward

Это единственный способ отправлять сообщения только тем пользователям, которым разрешено читать сообщение. Если вы этого не сделаете, то абсолютно ничто не может гарантировать вам, что это сообщение не будет прочитано купите хакера.

Что касается второго вопроса: то, что вы говорите, это то, что вы хотите защитить от DoS-атаки< /а>? Как правило, для этого нет решения. Одна вещь, которую вы можете сделать, это заставить сервер следить за тем, что излучает данный пользователь, и отключать пользователя, если он плохо себя ведет (что бы это ни значило :)).

И какое отношение перехват на стороне клиента имеет к замене JavaScript на что-то другое? Если вы отправляете данные клиенту, а затем клиент отправляет их обратно, то использование JavaScript или нет не имеет значения для хакера.

Это мой вам совет.

person freakish    schedule 05.03.2012