Могу ли я сделать форму с другого сайта

Question

У меня есть пользователь на веб-сайте A, и мне нужно зарегистрировать его на веб-сайте B (не под моим контролем), но без угрозы для его пароля на веб-сайте B. Веб-сайт B не имеет API, что делает это более сложным, чем должно быть.

Мой первый вариант - создать собственную форму на веб-сайте A, пользователь вводит пароль своего веб-сайта B в мою форму, и я каким-то образом безопасно передаю пароль его веб-сайта B на веб-сайт B, чтобы войти в него. Это означает, что я должен сначала пройти пароль надежно с клиента на мой сервер, а затем снова надежно передать его с моего сервера на конечный веб-сайт. Это то, что, я думаю, мне нужно сделать, но у меня нет плана, как безопасно реализовать эти 2 прыжка, поэтому я беспокоюсь, что могу как-то раскрыть пароль пользователя.

Так что я подумал о втором варианте, который заключается в том, чтобы сделать тот же веб-сайт B с веб-сайта B на моем веб-сайте. Но форма на веб-сайте B является частью большей страницы, так что это можно сделать?

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

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

Answer 1

Пока вы используете SSL на своем сайте, нет существенного риска с точки зрения компрометации пароля пользователя (если вы не совершаете какие-либо финансовые транзакции, пожалуйста, уточните).

Мое предложение: не копируйте их форму. Вместо этого скопируйте HTTP POST, созданный этой формой. Вы можете сделать это полностью программно, и пользователь никогда не покинет ВАШ сайт, но (в большинстве случаев) в результате пользователь также войдет на свой сайт.

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

Я использовал эту методологию против сайта Verizon и LinkedIn (оба для законных целей), и она работает.

Подведем итог:

1. Изучите структуру их HTTP POST.

2. Добавьте форму авторизации на ВАШ сайт.

3. Манипулируйте запросом в вашем коде, чтобы он выглядел как POST их сайт ожидает.

4. POST на свой сайт из вашего кода.

5. Отображение ответа пользователя на вашем сайте (при необходимости), перенаправить, что угодно.

Answer 2

Я постараюсь наметить решение, но оно может быть неверным или даже тем, что вы хотели, и оно определенно нецелесообразно.

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

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

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

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

---

Что я рекомендую:

Либо свяжитесь с сайтом назначения иустановить протокол, который вы можете использовать для аутентификации пользователя с вашего сайта.Для этого есть несколько действительно классных техник iframe.Прочитайте эту статью для компетентной презентации http://softwareas.com/cross-domain-communication-with-iframes.

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

Answer 3

Все зависит от того, как сервер, который вы размещаете на сервере, обрабатывает CSRF [подделки межсайтовых запросов], поскольку именно это вы и делаете. Если они используют, например, Django, который является относительно новым, то запросы POST от внешнего сервера по умолчанию не будут выполняться, если они не содержат значение файла cookie csrf.

Можно обойти это, если у вас есть контроль над сервером, на который вы также отправляете сообщение.

Answer 4

Я не совсем понимаю, что вы хотите сделать, если вы просто заходите на сайт, вы можете сделать что-то вроде этого:
Mainsite

<iframe id="logon" src="/logonto-other.html"></iframe>

/ logonto-other.html

<form onsubmit="top.logon.style.visibility='none';" action="http://other-site.com/login" method="post">
  <dl>
    <dt><label for="user">Name</label></dt>
      <dd><input name="user" />
    <dt><label for="pass">Password</label></dt>
      <dd><input name="pass" />
  </dl>
  <?php //code that acquires hash from other site
    // Don't know site B so can't write this one yet.
  ?>
  <input type="submit" value="Login" />
</form>

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

Что касается "2 прыжка", есть ли у вас сертификат и поддержка SSL / HTTPS на вашем сервере A? Есть ли у сервера B это? Как вы думаете, вы можете заставить пользователей доверять вам, имея свой пароль? Одним из советов может быть добавление параграфа, объясняющего ситуацию, и ссылку, по которой пользователь может связаться с сайтом B, чтобы оказать на них давление для реализации OAuth и / или OpenID?

Возможно, что-то удастся найти, даже если у вас нет HTTPS на вашем сервере, вы можете использовать JavaScript или Java-апплет для шифрования пароля (где-то в сети должен быть PGP в JavaScript. Хотя Если адресная строка браузера становится зеленой, пользователям легче принять решение, доверять ли вам.

Хотели бы получить ответы на некоторые мои вопросы, и можно ли нам узнать, что такое сайт B? И что именно вы пытаетесь сделать, может быть, мы сможем решить это вместе.

Желаю удачи.

Answer 5

См .: Сокеты

1. Изучите форму входа в SiteB HTML, чтобы собрать список имен полей, ожидаемых значений и URL-адреса действия.
2. Переделайте форму на свой сайт, используя те же имена полей.URL-адрес действия должен указывать на скрипт обработки на вашем собственном сервере.Предостережение на этом этапе - если сайт B использует какое-то специальное поле токена или набор файлов cookie при загрузке страницы формы входа.Если это так, используйте сокеты для подключения и получения новой копии страницы входа на сайт B.Вам нужно знать стандарты HTTP-сообщений и правильную структуру тела запроса , чтобы осуществить это.Затем проанализируйте полученный текст для поля токена или имен и значений cookie, которые будут использоваться на вашей собственной странице.
3. Пользователь вводит свое имя пользователя и пароль для сайта B в вашей форме.При отправке результаты формы передаются в ваш скрипт-обработчик.
4. Ваш скрипт-обработчик использует Sockets для подключения к цели URL-адреса действия сайта B в качестве обычного запроса POST.Этот запрос POST включает в себя любые файлы cookie и имена / значения токенов, которые Сайт B дал ему на предыдущих нескольких шагах.Вам нужно будет снова следовать рекомендациям по структуре сообщений протокола HTTP, чтобы выполнить это.
5. Сайт B аутентифицируется с использованием информации вашего пользователя.Ваш скрипт-обработчик сидит там в ожидании ответа.
6. Сайт B отвечает на скрипт-обработчик.Вам нужно изучить типичные ответы, возвращаемые сайтом B, чтобы узнать, как анализировать любой текст ответа (и снова научиться анализировать HTTP-сообщения), включая возвращенные заголовки файлов cookie.
7. Ваш сценарий обработчика должен где-то хранить журналсопоставление пользователя с любыми значениями cookie, возвращаемыми после успешной аутентификации сайтом B. При любых будущих запросах к сайту B, снова используйте сокеты, чтобы маскировать их как пользователя, передавая заголовок cookie / val, используемый для идентификации их (IE: your ) сеанс входа на сайт B.

Имейте в виду, что вы можете вести открытый и честный диалог о том, что вы делаете с сайтом B, или вы можете быть ответственным загражданский иск .

Answer 6

Чтобы изолировать форму от большей страницы, найдите теги <form> и </form> и скопируйте только любые элементы между ними.Теперь поместите эту форму на свою страницу, и ее действие все еще будет указывать на URL-адрес, на который она указывала на исходном веб-сайте.Пароль никогда не проходит через ваш сервер.

Answer 7

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

Несколько человек предложили разместить форму на PHP-файле на вашем сервере и разрешить вход с сервера на сервер.Это решение почти никогда не работает.Даже если сайт B примет ваш логин сервер-сервер (что, вероятно, так и будет, поскольку вы можете подделать любой браузер, какой захотите), это будет ваш веб-сервер, который будет получать новые куки, и ваш IP-адрес веб-сервера, с которым будет связан сеанс.Даже если вы вернете cookie в браузер, он сохранит его для вашего сайта (сайта A) и не отправит его на сайт B, когда браузер попадет туда, поэтому пользователь останется в системе изсайт B.

Итак, единственное, что вы можете здесь сделать, - это разместить на своем сервере форму входа для своего сайта.Это означает, что вам нужно будет отправить форму в браузер, в которой есть ДЕЙСТВИЕ, которое указывает на форму входа сайта B.Это также означает, что всякий раз, когда пользователь нажимает кнопку входа в систему, управление передается на сайт B: пользователь будет уходить с вашего сайта, и вы его потеряете.

У этого второго метода есть две основные технические проблемы: одна из них заключается в том, что сайт B может иметь предотвращение XSS и может фактически блокировать публикацию материалов на их странице входа в систему.Другая проблема заключается в том, что если ваш сайт работает по протоколу SSL, браузеры будут мучительно ждать, когда вы отправите форму на другой сайт.Ничего из этого вы не можете решить самостоятельно.

Единственным чистым решением было бы по-настоящему сесть за сайт B и составить план общей аутентификации или, по крайней мере, API аутентификации.Вы можете попробовать решение для кросспостинга, но есть вероятность, что у вас возникнут проблемы, которые вам не нравятся.