Безопасно отправлять данные по HTTP через домены

Question

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

Есть много способов сделать это, в настоящее время я планирую зашифровать необходимые данные регистрации / входа и перенаправить конечного пользователя с этими данными в скрытом фрейме, чтобы конечный пользователь не беспокоился об этом процессе. (это будет рассмотрено на сайтах T & C). Сейчас он уже использует SSL, но я хочу сделать этот процесс максимально безопасным. В настоящее время я зашифровываю отправленные данные ключом, который ведущий и ведомый оба хранят в своей конфигурации. Я обеспокоен тем, что кто-то может взломать это, поскольку ключ всегда один и тот же, и я думаю об использовании соли вместе с тем ключом, который мастер должен будет получить от ведомого устройства для каждого отдельного запроса, но это удваивается необходимое количество HTTP-запросов.

Мне просто интересно, переоцениваю ли я это, или я слишком осторожен (в конце концов, одного SSL теоретически должно быть достаточно).

Какой совет? Спасибо

Answer 1

В большинстве случаев SSL должно быть достаточно. Если сертификат и закрытый ключ сервера хранятся надежно, отзыв сертификата регулярно проверяется, закрытый ключ не является слабым (и т. Д.), Канал между браузером конечного пользователя и вашим сервером (а также канал между главный и подчиненные сайты) будут защищены от прослушивания, что не позволит другим пользователям видеть учетные данные.

Что SSL не делает, так это аутентификация "клиентской" стороны соединения, то есть любой, кто знает правильные URL-адреса, может подключиться, аутентифицироваться (выдавать себя за подчиненный сайт) и получать токен аутентификации / входа (, если *) 1004 * предоставленные учетные данные верны). Это означает, что при наличии токена ваш главный сервер не сможет определить, какой сайт выполняет «привилегированные» функции. Сами учетные данные останутся защищенными с помощью SSL, и злоумышленнику все равно потребуется знать их для выполнения атаки. (Я предположил, что на самих сайтах нет других ошибок, таких как уязвимости XSS или неправильное управление файлами cookie).

Тем не менее, вы должны использовать ключ (или секрет в форме строки) и передавать его с подчиненных сайтов на главный только , если вам нужно управлять разрешениями внутри этой сети на высокий уровень детализации (например, запрет на вход на определенных сайтах и ​​разрешение на других на основе личности пользователя, или временное запрещение входа на определенные сайты, если некоторые из них не находятся под вашим непосредственным контролем и вы подозреваете компромисс) если это так, я предлагаю вам взглянуть на OAuth-сайт , это протокол, разработанный специально для этой цели (вы можете просто написать API, который позволяет входить в систему и получать необходимые данные с главного сервера).

Если (и только если) все сайты находятся под вашим непосредственным контролем, достаточно использовать только SSL; нагрузка на управление двумя наборами ключей (один для SSL и один для дополнительного шифрования) была бы слишком высокой, и серверы использовали бы слишком много ресурсов. Только убедитесь, что SSL используется между браузерами и серверами, а также для всей связи между самими серверами, для защиты от перехвата сети.