Междоменные сессии и веб-сокеты

Question

Я работаю над сайтом, который будет использовать HTML5-сокеты для связи с другим сервером.В это время наши пользователи будут авторизованы, я не могу написать код на другом сервере.Я использую PHP на стороне сервера.Я не знаю, есть ли на другом сервере даже PHP или нет.Клиент говорит, что PKI - это решение.Поэтому, если пользователь входит на наш сервер, я начинаю его общение с HTML5-сокетами по направлению к другому серверу для отправки и получения данных.Так как же другой сервер может их аутентифицировать?Я также думаю, что у меня может быть пользовательский ключ (например, формат 32hash), который отправляется с сокетом HTML5 во время связи, которую другой сервер проверяет, и затем начинает работать с этим пользователем.Так что клиент говорит, что хакер может видеть данные по сети, поэтому я думаю, что SSL может работать на него.Что вы, ребята, предлагаете в таком сценарии?Пожалуйста, сообщите

Подробнее:

Будет установлено соединение между нашими пользователями и другим сервером, использующим Apache Thrift (будет использоваться TCP), и сценарий таков, что пользователь войдет на наш сайт, затеммы подключим их через HTML5socket к Apache Thrift в другом домене, поэтому в связи с HTML5socket мы будем переадресовывать userid, чтобы сообщать Thrift-серверу, что это за пользователь, так что все в порядке.Но есть две проблемы:

1. Поскольку HTML5sockets находятся на стороне клиента, тогда хакер может создать свой собственный сокет и подключиться к этому серверу таким же образом и использовать какой-то идентификатор, так как это просто целые числа,
2. Если мы добавим что-то в данные, то хакер, сидящий в сети, может получить это, как это делают некоторые хакеры для перехвата сеанса.

Поэтому я не уверен, чтоиспользование какого-либо типа SSL или TLS решит проблему или какой-либо PKI или какой-либо другой цифровой сертификат.Вот почему я спрашиваю об этом здесь.

спасибо

Answer 1

SSL не может решить эту проблему.SSL предназначен для создания безопасной связи между клиентом и сервером, он абсолютно ничего не делает для защиты сервера от вредоносного клиента.SSL не может решить проблему SQL-инъекции или, в вашем случае, небезопасная прямая ссылка на объект , связанная с идентификатором пользователя.Судя по этому предложению SSL, вы, вероятно, никогда не слышали о TamperData , который позволяет вам читать / перехватывать и изменять весь HTTPS-трафик, генерируемый вашим браузером (включая такие компоненты, как flash и JavaScript), BURP более продвинут, но делаетто же самое.

Правильный способ сделать это - иметь общее хранилище сеансов, к которому ваша коллекция серверов может получить доступ.Клиенту выдается очень большое случайное число или криптографический одноразовый номер , который он использует в качестве токена проверки, что похоже на идентификатор сеанса.Этот токен проверки используется для поиска состояния сеанса в хранилище данных.Общее хранилище сеансов может быть таким же простым, как страница PHP, которая принимает маркер проверки в качестве параметра и сообщает вам, связано ли оно с действительным сеансом.

Если третьи стороны выдают обратный вызов для проверки того, что сеанс действительно «Правильный путь» , чтобы сделать это.Это можно сделать с помощью криптографии, хотя криптография используется не по назначению, поскольку она создает возможность атаки, когда обратный вызов является абсолютным.Сервер PHP может выдать клиенту JavaScript токен HMAC , состоящий из идентификатора пользователя, отметки времени и кода аутентификации сообщения.Сложность в том, что и сервер PHP, и любая третья сторона должны будут поделиться секретом, чтобы проверить код аутентификации сообщения.Если все сделано правильно, вы можете передать, что клиент может передать токен, и третьи стороны могут проверить, что сеанс не истек, основываясь на отметке времени, и что ваши серверы выпустили токен (вместо подделки хакера) на основе кода аутентификации сообщения.