Cookies являются частными для целевого клиента. Это не отличается для socket.io или для входа в Google. Если сервер хочет защитить их, то вы запускаете соединение по протоколу https, и оно полностью шифруется, и единственным, кто имеет доступ к этим файлам cookie, является сам клиент. Именно так браузеры выполняют вход и идентификацию ранее аутентифицированного клиента.
Кроме того, идентификатор session.io не должен быть секретом. Это ничего не разрешает. Он просто идентифицирует клиента как того же клиента, что и предыдущий. Если приложение хочет, чтобы этот клиент был аутентифицирован и защищен, то это должно происходить по-другому. Нет никакой аутентификации, связанной с socket.io cook ie.
Если вы используете express -сессию и хотите, чтобы она была безопасной, то вам нужно использовать сквозную конец https. Это защищает сессионного повара ie в пути. Да, если ваш клиент скомпрометирован, и кто-то украл сессионный повар ie и использует его до истечения срока действия, он может захватить сессию. Но именно поэтому вы используете https, поэтому нет способа получить сессионный повар ie из середины транспорта. Итак, что должно быть защищено, так это сам клиент. И это то же требование, что и на каждом веб-сайте, который использует аутентификацию. Это веб-архитектура, ничего нового для socket.io или express -session.
Так что же произойдет, если каким-то образом ваш компьютер будет взломан и хакер получит доступ к браузеру клиента, и, следовательно, куки и идентификатор сессии? Тогда они не будут угонять сеанс, пока он транспортирует
Во-первых, вы можете быстро истечь ваши куки (например, в течение 5 минут бездействия). Вы увидите, как это делают банковские сайты.
Тогда у вас возникнут гораздо большие проблемы, если сам компьютер будет взломан. Злоумышленник может внедрить кейлоггеры или другие шпионские программы и может украсть ваши фактические учетные данные для входа не только для вашего веб-сайта, но также для электронной почты и других подобных вещей.
Существуют более высокие уровни безопасности, чем просто имя пользователя и пароль для входа Например, вам может потребоваться физическое оборудование, которое либо подключается к вашему USB-порту, либо требует, чтобы вы вводили код (который постоянно меняется) с устройства. Я работал в компаниях, которым требовалось такое устройство для входа в сеть компании вне корпоративной локальной сети. Это одна из форм так называемой «двухфакторной» аутентификации.
Если вы смотрите на веб-сайты как на банки, они, как правило, обнаруживают входящий в систему компьютер, и если он выглядит как незнакомый компьютер (отсутствуют другие файлы cookie, другой IP-адрес, другой пользовательский агент, другое разрешение экрана и т. д. c ...), тогда они требуют дополнительных шагов входа в систему, таких как отправка кода на телефон, который необходимо ввести, прежде чем вы сможете войти в систему in. Или они требуют, чтобы вы ответили на дополнительные личные вопросы, прежде чем впустить вас. Они также могут уведомить владельца учетной записи, что для входа в систему использовался новый компьютер. Если это был не вы, go измените / повторно получите учетные данные своей учетной записи.
Не могли бы вы предложить для решения этой проблемы перенаправить весь мой сайт с HTTP на HTTPS?
Да. Любой сайт, заинтересованный в безопасности, должен иметь доступ через https.
. В Интернете много написано об этой теме c. Вы можете начать с чтения статей здесь: https://www.google.com/search?q=best+practices+for+securing+login