Безопасность аутентификации WebSocket

Я пытаюсь выполнить аутентификацию клиента на моем безопасном сервере WebSocket (wss) для зарегистрированной области пользователя.

Как только член подключен к веб-серверу, я записываю в базе данных уникальный токен (связанный с членом), который я отобразил в скрытом поле на странице, инициирующей соединение с сервером веб-сокета.

Затем токен отправляется на сервер WebSocket, который аутентифицирует учетную запись, используя токен.

Я действительно не эксперт по безопасности, и я хотел бы получить ваше мнение относительно безопасности моей аутентификации.

Существуют ли какие-либо риски (кроме захвата файлов cookie)? Есть ли лучший способ продолжить рассмотрение, считая, что WebSocket не предписывает какой-либо особый способ, которым серверы могут аутентифицировать клиентов во время установления связи WebSocket.

Я использую Ratchet WebSocket.

Ответ 1

Да, один из вариантов - использовать файлы cookie (и TLS, чтобы избежать захвата файлов cookie):

Установите cookie после "простой старой HTML-формы", войдите в систему, передайте файл cookie на сервер WebSocket и используйте cookie для аутентификации WebSocket.

Вот полный пример для проверки подлинности на основе Mozilla Persona с помощью WebSocket.

Вы спросили о Ratchet. Этот пример не является Ratchet, но он может дать вам некоторые подсказки - вот почему я думаю, что это нормально, чтобы указать на.

Ответ 2

Есть ли риск...

Да, много. PKI/PKIX и SSL/TLS имеет ряд архитектурных недостатков. Для полного лечения см. Peter Gutmann Инженерная безопасность.

Кроме того, WebSockets не позволяет запрашивать атрибуты базового соединения. Итак, насколько я знаю, вы даже не можете сказать, действительно ли вы используете SSL/TLS. Единственное, что вы узнаете, это вы попросили его.

Есть ли лучший способ продолжить рассмотрение WebSocket

В прошлый раз, когда я проверил, WebSockets довольно хромой. Все, что вам нужно сделать, это open, read и write. Они предназначены для простой в использовании, но не имеют ничего полезного в отношении безопасности.

Для полноты, последний раз, когда я проверил, был март 2013 года при выполнении оценки безопасности в приложении, которое их использовало. Возможно, теперь все изменилось.

Я также попытался привлечь авторов WebSockect RFC, а редактор RFC о некоторых проблемах стал точкой зрения безопасности. Все электронные письма остались без ответа.

UPDATE (2015): он становится еще лучше... Браузеры и другие агенты пользователей Закрытие публичного ключа хоста сейчас.

Но если вы посмотрите на детали, его следует называть "Перенос публичного ключа хоста с переопределениями". Встроенные переопределения позволяют злоумышленнику разбить хороший пинсет. Хуже того, браузер причастен к сокрытию, потому что он ДОЛЖЕН подавить неудачный отчет о выводе.

Вы можете прочитать больше жалоб по этому поводу (и опровержение) в Комментарии к черновику-ietf-websec-key-pinning.

Его стандарт нежелательной почты, который никогда не должен был быть стандартизирован. Его более небезопасный браузерный мусор.