Предоставление безопасного доступа с одного сайта на другой

Question

Я действительно просто смотрю, как много глупости в нижнем предложении с точки зрения безопасности.

У меня есть два веб-сайта. Один из них - портал администрирования, а другой - портал участников.

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

Оба являются отдельными веб-сайтами в рамках IIS, и для этой дискуссии можно сказать, что они находятся на разных серверах.

Оба сайта обращаются к одной и той же базе данных SQL Server.

Я думал, что мог бы администратор щелкнуть ссылку «Вход как член», создать случайную строку кода и сохранить ее в базе данных вместе с номером участника.

Затем я мог передать код и номер участника на портал-член как параметры строки запроса.

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

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

Возможно, это маловероятно, учитывая, что между генерируемым кодом и используемым кодом будут проходить только секунды.

При необходимости я всегда могу проверить IP-адрес запроса, поскольку пользователи портала администрирования имеют общий фиксированный IP-адрес.

Как вы думаете, вышесказанное будет стоять на рассмотрении в обзоре безопасности или мне нужно будет спуститься по маршруту SSO?

Answer 1

Ваш подход очень прост.Я могу подтвердить, потому что я реализовал именно такое решение именно по этой причине. Мы проанализировали варианты и экспозицию. И после внедрения наша заявка прошла PCI Complaince Audit.

Причина:

• SSL является Эссенциальным! защищает от снифферов. Essential. Без шифрования, снифферы могут обнаружить ваш идентификатор GUID и могут иметь окно для его использования)

• Как указал Тони, GUID фактически неопровержимо.

• Руководство Токены, срок действия которых истекает , истекает в течение 24 часов.

Предложения:

• Проверка против IP хорошо. Но не обманывайте себя чувством безопасности от него. Любой может поддельные IP-адреса в заголовках. Для защиты от XSS и CSRF с использованием AntiForgery tokens.

Маркер AntiForgery это печенье, который заполнит ваш HTTPHeaders с __RequestVerificationToken, который почти так же трудно угадать, как ваш GUID.

• Рассмотрите возможность использования установленной системы аутентификации, такой как .NET Identity 2 и многопользовательской.

Установленная структура берет на себя ответственность за шифрование ваших паролей. MS Каркасы как Простого членство и идентичность интеграция в современные рамки ASP.NET и дать вам очень сильную базу функциональных возможностей, чтобы опереться.

Если вы используете старый фреймворк, такой как классический ASP или .NET 2.0, более подходящим является classic Membership Provider.

Если вы создаете новый MVC 5 приложений с использованием Entity Framework, я настоятельно рекомендую использовать Идентичность 2,1.

• Рассмотрите возможность многоквартирного дома. Хотя в вашем решении нет ничего плохого, если Admins и пользователи поделились с поставщиком членства, ваше решение было бы более чистым. Администратор может войти в основной сайт и «получить» токен из БД. Тогда нет воздействия.

Answer 2

Предполагая использование HTTPS и соответствующих процессов и процедур физической и информационной безопасности для администраторов, этот метод должен быть адекватным. Он более безопасен, чем большинство финансовых списаний пароля веб-сайта, для которых обычно требуется только скомпрометированная учетная запись электронной почты и некоторые личные данные для сброса пароля. Если вы также проверите диапазон IP-адресов исходящего запроса клиента, хакеру придется уже иметь доступ к вашим системам или сети. Кроме того, если вы сделаете код GUID, это было бы (прагматично) невозможным для кого-то угадать.

Вы можете добавить уровень проверки на попытки взлома, записав запись в базе данных каждый раз, когда это событие происходит (или, по крайней мере, каждый из них сбой из-за плохой клавиши), и каждый раз, когда это происходит, выполняется проверка, чтобы увидеть если это происходит слишком часто (например, 100 раз за прошлый час или что-то в этом роде - правильное количество зависит от того, как часто вы ожидаете, что это произойдет). Если это происходит слишком часто, отправьте предупреждение персоналу ИТ и верните его, чтобы пользователь вручную вводил свои учетные данные.

Отказ от ответственности: Я не являюсь экспертом по безопасности любым способом, поэтому я с удовольствием отнесусь к любому, кто утверждает такой статус. Я взвешиваюсь здесь из-за отсутствия ответов.