Comments 5
Фундаментально! В следующий раз, когда мне будут в очередной раз говорить, какая классная и простая технология WS - я буду знать куда отправлять за весёлым чтением.
Не могли бы вы прояснить про SSE: если требуется установка соединения 1 раз, при условии что токен живёт долго, разве недостаточно передать токен при установке соединения через обычные куки?
Для аутентификации запроса — достаточно, это как раз один из доступных способов.
Однако остается вопрос контроля валидности соединения. Поскольку в данном случае природа передаваемых сообщений асинхронна и само HTTP-соединение остается открытым в течение некоторого времени, у нас все так же имеется риск передать некую важную информацию в сообщениях, даже если токен по любой причине будет инвалидирован. Инвалидация токена по истечении максимального времени жизни — это часто не единственная причина, есть, например, тот же логаут (выход по инициативе пользователя), отзыв токена в связи с различными событиями.
Естественно, степень критичности данного риска для каждого своя, допускаю, что в ряде приложений последствия могут быть не такими серьезными.
Спасибо за статью! Я бы ещё добавил момент с аутентификацией в механизм ping-pong помимо аутентификации при отправке сообщений на сервер
В браузере этот механизм фактически не работает.
Интересно, что даже лабораторная у PortSwigger по CSWSH сделана в тех же тепличных условиях — с сессионной cookie, у которой выставлен
SameSite=None. Причем явно об этом не пишут.
В защиту PortSwigger скажу, что эту лабораторную они выпустили в свет в 2019 году, когда SameSite еще не был по умолчанию Lax. Помню, потому что тогда сам решал эту лабу) Примерно в то же время эксплуатировал CSWSH на пентестах, и SameSite никак не мешал.
Аутентификация для WebSocket и SSE: до сих пор нет стандарта?