#security #https #single-sign-on #token
#Безопасность #https #единый вход #токен
Вопрос:
У меня есть два веб-сайта на разных серверах, и мне нужно разрешить единый вход с одного сайта на другой. Оба веб-сайта имеют доступ к одной и той же базе данных. Пользователи уже прошли проверку подлинности и пользуются доверием на веб-сайте A, но я бы хотел, чтобы они нажимали на ссылку и автоматически входили в систему и перенаправлялись на веб-сайт B. Я изучил SAML и другие параметры единого входа, но поскольку оба сайта могут обращаться к одной и той же базе данных, мне интересно, могу ли я использовать простой токен для разрешения единого входа?
Настройка:
www.websiteA.com > databaseA
www.websiteB.com > databaseA
Я думал о чем-то вроде:
www.websiteA.com/sso.php- Создайте случайную запись токена в базе данных, связанную с этим пользователем, скажем, ABCD1234
- Перенаправление на
www.websiteB.com/login.php?token=ABCD1234- Проверьте DatabaseA на наличие этого токена и войдите в систему связанного пользователя
Является ли это безопасным способом выполнения единого входа между этими двумя веб-сайтами? Является ли переменная URL безопасной, если она выполняется по протоколу HTTPS и если токен уничтожается только после его использования?
Ответ №1:
Я думаю, что общая идея создания токена на сайте A и передачи его на сайт B в качестве средства аутентификации может быть приемлемой во многих случаях. В этом нет принципиальных недостатков, хотя, как вы упомянули, наилучшей практикой является выполнение этого стандартным способом, например, OAuth2 (OpenID Connect для идентификации).
Однако, как всегда, детали имеют большое значение.
Токен должен быть сгенерирован надежно (на основе криптографически безопасного генератора случайных чисел), должен иметь достаточную энтропию (~ достаточно долго), его необходимо надежно передавать, надежно хранить на клиенте (если вообще, но он всегда будет храниться в памяти, по крайней мере), проверка наконечный получатель не должен быть уязвим для состояния гонки (злоумышленник и жертва отправляют токен одновременно, два потока на сервере оба проверяют, действителен ли токен, оба находят его, затем оба аннулируют его, но это не имеет значения, токен был действителен для них обоих) и т.д.
Единственная реальная слабость с точки зрения безопасности в вашем вопросе, которая, я думаю, делает ваше предлагаемое решение напрямую уязвимым, — это передача токена в URL. HTTPS защищает от злоумышленника, подслушивающего, но параметр url может быть зарегистрирован на промежуточных прокси-серверах (например, корпоративный пользователь может даже не знать о таких прокси-серверах, и они многократно прерывают SSL, используя корпоративные сертификаты, которым доверяют клиенты), это может быть запомнено в клиентском браузере, может получитьзарегистрирован на целевом сервере и т. Д. Если токен действителен только до его первого использования, это несколько снижает риск, но было бы лучше отправить его в теле запроса (POST) вместо параметра url.