Подтвердить что ты не робот

Защита веб-узлов

В настоящее время наше приложение разработано для облегчения всей связи через веб-ячейки после начальной загрузки.

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

До сих пор мы думаем о нескольких вещах:

  • Аутентификация транспорта websocket путем передачи уникального хэш, хранящийся в файле cookie сеанса, который был отправлен через SSL при начальной загрузке.
  • Клиентское шифрование с использованием чего-то вроде javascript bcrypt чтобы зашифровать все до его транспортировки.

  • Просто передайте все конфиденциальные данные с обычной почтой через SSL даже хотя мы этого не хотим.

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

Любая помощь, позволяющая справиться с возможными сбоями в системе безопасности или любые другие идеи о том, как добиться подлинной безопасности над веб-сайтами, будет с благодарностью!

4b9b3361

Ответ 1

Подключение к URL wss:// WebSocket вместо ws:// будет использовать стандартное шифрование TLS/SSL браузера для подключения к серверу. Это эквивалентно HTTPS и HTTP. Если вы доверяете реализации браузера SSL/TLS, вы можете доверять соединениям WebSocket wss://, так как они используют один и тот же движок. Вам нужно будет иметь подписанный SSL-сертификат, настроенный на вашем сервере websocket, но это в значительной степени требуется в любом случае.

Ответ 2

Что касается файлов cookie, то стоит подумать, что (в настоящее время) спецификация протокола WebSockets не требует, чтобы браузер предоставлял все или даже какие-либо файлы cookie, установленные веб-сервером, изначально обслуживающим JavaScript, который вы использовать для открытия соединения с WebSockets на этом сервере.

См. здесь для описания того, как ведет себя Firefox (от разработчика FF).

Ответ 3

Защита (шифрование с использованием SSL/TLS) очень важна для ваших данных. Но вы должны также рассмотреть возможность аутентификации. Любой, у кого есть устройство с поддержкой ws, которое знает вашу конечную точку для вашего сервера, сможет получить данные, если сначала не требует проверки подлинности. См. http://simplyautomationized.blogspot.com/2015/09/5-ways-to-secure-websocket-rpi.html Включает трехсторонний метод установления связи (CHAP), который требует, чтобы клиент и сервер имели "предварительно разделяемый секрет".
Другие способы подробно описаны на этой должности.

Приветствия