1

Если я нахожусь на веб-сайте №1, и я ввожу свое имя пользователя/pwd для сайта № 2 на странице входа, которая находится на веб-сайте № 1, а на сайте № 1 за кулисами, делает httpwebrequest на веб-сайте № 2 и сообщений на страницу входа. Если я затем перейду на сайт №2, должен ли я войти в систему?Можно ли аутентифицироваться на другом веб-сайте?

сайт # 2 использует форму аутентификации, и я вызываю httpHandler, который находится на веб-сайте №2, и передайте ему имя пользователя/пароль с помощью строки запроса.

Должно ли это работать?

+0

Использует ли сайт # 1 также FormsAuthentication? – Josh

+0

Джош, да. – Blankman

ответ

1

То, что вы пытаетесь сделать, называется Single Signon. То, как вы это делаете, отправляя значения с одного сайта на другой, вероятно, не будет работать, потому что вы используете ту же технику, которую может использовать хакер, чтобы обмануть пользователя в обмене информацией для входа в систему. Это называется атакой cross-site request forgery. IIS настроен таким образом, чтобы не допускать этого.

Как правило, вам нужна центральная система аутентификации, которую используют оба сайта для совместного использования информации для входа. Это можно сделать несколькими способами, включая общую систему входа на базе базы данных. Google «asp.net one sign on» для большего количества идей.

+0

IIS НЕ предотвращает атаки XSS! Атаки XSS предотвращаются только браузером и могут быть отключены пользователем. Поскольку он выполняет запрос на сервере, IIS будет любезно разрешать запрос, как если бы он поступал от любого обычного клиента. Хакер использовал бы JavaScript, встроенный в страницу, чтобы сделать запрос за кулисами на другой сайт и попытаться олицетворять пользователя, используя свои файлы cookie. Выполнение запросов на стороне сервера из одного домена в другой - это обычный обыденный материал. – Josh

+0

Вот почему я сказал, что кросс-сайт-запрос подделки (CSRF) НЕ межсайтовый скриптинг (XSS.) –

+0

Я приговариваю, поскольку я хотел поставить CSRF как сокращенное, но если вы посмотрите на то, что я описал, это на самом деле Подделка запроса на перекрестный поиск. Аргумент все еще стоит. – Josh

0

Это может работать, в зависимости от мер безопасности, размещенных на веб-сайте №2. Для безопасного веб-сайта это провалится.

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

Если вы не знаете, какие меры безопасности прекращают это, вы должны, вероятно, обучить себя, чтобы вы могли предотвратить те же проблемы на своем собственном сайте. См. http://www.owasp.org/index.php/Top_10_2007

0

Хотя это может быть сделано в некоторых случаях в виде HTTP-запроса с параметрами POST, вы не будете аутентифицированы после перехода на сайт # 2.

Это связано с тем, что в целом эти сайты хранят файл cookie на вашем конце, и это основано на домене, что означает, что даже если вы его захватили и сохранили непосредственно с сайта # 1, имя файла cookie не будет соответствовать сайту # 2.

Кроме того, сайт №2 не может быть легко аутентифицирован, и это, как правило, проблема безопасности, о которой знают разработчики. Это можно считать попыткой XSS.

Если вы просто делаете это для себя, я бы рекомендовал LastPass и сохранить большую часть вашей информации в нем.

Пожалуйста, пересмотреть свои цели и как их достичь, это не так.

Редактировать: Текст ссылки.

0

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

Это позволит сделать Cross Application Authentication автоматически :)

1

Do сайт # 1 и # 2 хотят, чтобы их пользователи имели единый вход? Если это так, ознакомьтесь с одним знаком. Это более крупный проект, чем можно здесь рассмотреть. Есть хорошая книга об этом, хотя от Wrox: http://www.amazon.com/Professional-ASP-NET-Security-Membership-Management/dp/0764596985/ref=cm_lmf_tit_10

Или мы представляем что-то зловещее?
Если мы воображаем что-то зловещее, тогда злой сайт № 1 будет собирать учетные данные, а затем автоматизировать браузер на стороне сервера, чтобы начать проверку, чтобы определить, использует ли сайт # 2 тот же пароль и комбинацию пользователей. Тогда сервер будет иметь аутентифицированный сеанс. Это не даст пользователю, который обратился к сайту №1, к файлу cookie, объект HttpWebRequest на сервере получит файл cookie auth. Сайт №2 не мог ничего сделать, чтобы предотвратить это, потому что запрос браузера с одного компьютера похож на запрос браузера от другого. Хорошо обработанная атака обманет все элементы запроса браузера, чтобы он выглядел так, как будто он пришел из браузера, а не из примитивного объекта HttpWebRequest, который даже не может установить пользовательский агент.

Сайт №2 должен прекратить использование паролей и идентификаторов пользователей или использовать 2 идентификатора фактора, если они касаются этого, или сделать что-то, что требует javascript для входа в систему, поскольку подмена браузера, выполняющего javascript, сложнее, чем спуфинг браузера, который просто отправляет и принимает HTTP-запросы и ответы.

1

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

Мы используем CA Siteminder для проверки подлинности через сайт. Эффективно web 1 создает уникальный идентификатор сеанса на сервере siteminder и передает ему любые учетные данные и информацию. Siteminder вызывает web2 и передает информацию с помощью переменных сеанса. Web 2 извлекает данные из сеанса и использует его. Там гораздо больше происходит, но все в порядке.

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

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

  • Нет связанных вопросов^_^