2009-06-07 2 views
0

Если я пытаюсь защитить свой метод входа в систему. С незащищенного сервера пользователь вводит свои учетные данные в стандартную форму HTML, которая представляет собой POSTing для скрипта на защищенном сервере. Этот скрипт выполняет все необходимые функции входа и отправляет пользователя обратно на небезопасный сервер.Безопасный вход в систему

Мой вопрос сводится к следующему: информация, связанная с регистрацией, зашифровывается через SSL до того, как она отправляется на защищенный сервер, поэтому предотвращает обнюхивание пакетов в режиме «человек-в-середине». Или все по-прежнему отправляется в ясном виде, и форма, выполняющая POSTing, также должна размещаться на защищенном сервере?

Благодаря

ответ

1

Если вы размещаете через SSL, то информация будет путешествовать по сети в зашифрованном виде и предотвратит перехват пакетов.

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

Другой вопрос, который у меня есть, заключается в том, как незащищенный сервер «знает», что пользователь фактически прошел аутентификацию с помощью защищенного сервера? Если это делается с помощью файлов cookie или переадресации браузера (оба из которых будут незашифрованы, поскольку пользователь будет отправлен обратно на незащищенный сервер), эта информация будет легко прочитана любым пользователем на проводе. Это может быть быть безопасным отверстием, где учетные данные пользователя фактически защищены, но ваше приложение/веб-сайт не защищены от доступа лицами, которые фактически не аутентифицировались.

Смежные вопросы