我可以从其他网站呈现表单吗

Question

我在网站 A 上有一个用户，我需要让他登录到网站 B（不在我的控制之下），但又不能危及他在网站 B 上的密码。网站 B 没有 API，这使得事情变得比应有的更加复杂。

我的第一个选择是在网站 A 上呈现我自己的表单，用户在我的表单中输入他的网站 B 密码，然后我以某种方式安全地将他的网站 B 密码传递到网站 B 以让他登录。这意味着我必须首先安全地传递密码从客户端到我的服务器，然后再次将其安全地从我的服务器传递到最终网站。这就是我猜我必须做的，但我没有计划如何安全地实现这两个跃点，所以我担心我可能会以某种方式暴露用户的密码。

所以我想到了第二种选择，即将同一个网站B从网站B渲染到我的网站上。但是B网站上的表单是一个更大页面的一部分，那么这样可以吗？

• 的整页代码隔离开来
• 我如何将表单本身的代码与如何在我的网站上呈现表单 。我希望用户看到它。我想到了 iframe，但从未使用过它
• ，当用户单击提交按钮时，表单仍然有效，或者在我的网站上渲染表单以某种方式使其无效，

这是我想到的两种不同的解决方案。我欢迎他们每个人的答案，也欢迎提出可能更容易的替代第三种方法的答案。

Answer 1

只要您在网站上使用 SSL，就不会存在泄露用户密码的重大风险（除非您正在进行某种金融交易，那么请澄清）。

我的建议是，不要复制他们的表格。相反，复制该表单生成的 HTTP POST。您可以完全以编程方式完成此操作，并且用户永远不会离开您的网站，但（在大多数情况下）结果将是用户也登录到他们的网站。

如果需要处理某种散列字段，请请求其表单页面（以编程方式）并使用您收到的任何值将发回到第二个站点，以便请求得到验证。他们的服务器不知道请求不是来自浏览器（事实上，如果您愿意，您可以将用户代理添加到 HTTP 标头）。

我已经对 Verizon 网站和 LinkedIn（均出于合法目的）使用了这种方法，并且它有效。

回顾一下：

1. 了解其 HTTP POST 的结构。

2. 向您的网站添加登录表单。

3. 在代码中处理请求，使其看起来像 POST 他们的请求
   网站期望。

4. 从您的代码发布到他们的网站。

5. 在您的网站上显示对用户的响应（如果需要），
   重定向，无论如何。

Answer 2

这完全取决于您要发布的服务器如何处理 CSRF [跨站点请求伪造]，因为这基本上就是您正在做的事情。例如，如果他们使用相对较新的 Django，那么来自外部服务器的 POST 请求默认会失败，除非它们包含 csrf cookie 值。

如果您也可以控制要发布到的服务器，则可以解决此问题。

Answer 3

我将尝试概述一个解决方案，但它可能不正确，甚至不是您想要的，而且绝对不切实际。

根据我对 XSRF 的了解，如果目标站点做好了功课，您将无法模仿从您的域提交的表单。

除了目标站点之外，唯一有权访问用户凭据的就是浏览器。所以你真正需要做的是成为一个浏览器。这意味着您必须让用户相信他可以将他的登录信息交给您到其他站点。我不知道你怎么能做到这一点，我个人不会相信这样的事情。 （另一种选择是欺骗他（网络钓鱼），但这是非法的，我认为您甚至不会考虑它。）

在您设法说服用户向您提供他的数据后，您仍然必须表现得像一个浏览器。您必须实现一个为每个用户存储 cookie 的系统，以便在您登录时创建会话。

这样做后，您将使用用户的数据登录，但用户不会< /强>。因此，您还需要通过您的网站实现用户需要的任何其他操作。

---

我的建议：

联系目标站点并设置可用于对站点中的用户进行身份验证的协议。有一些非常酷的 iframe 技术可以做到这一点。阅读本文，了解精彩的演示 http://softwareas.com/cross-domain-communication- with-iframe 。

或者让用户打开一个弹出窗口，其中包含该站点的登录页面。确保弹出窗口的地址栏可见。

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 hop”的事情，您的服务器 A 上有证书和 SSL/HTTPS 支持吗？ B服务器有这个吗？您认为您能让用户信任您拥有他们的密码吗？一个提示是您添加一段解释情况的段落和一个链接，用户可以在其中联系站点 B 以向他们施加压力以实施 OAuth 和/或 OpenID？

即使您的服务器上没有 HTTPS，您也可以使用 JavaScript 或 Java 小程序来加密密码（网络上的某个地方必须有 JavaScript 中的 PGP），也许可以很好地找到某些内容。尽管如此，如果浏览器地址栏变绿，用户可以更轻松地决定是否信任您。

想知道我的问题的答案吗？我们可以知道站点 B 是什么吗？也许我们可以合作。 。

祝你好运

Answer 5

要将表单与较大的页面隔离，请找到

和

标记，并仅复制它们之间的任何 和 元素。现在将该表单放在您的页面上，其操作仍然指向它在原始网站上指向的 URL。密码永远不会通过您的服务器。

Answer 6

参见：Sockets

1. 研究 SiteB 的登录表单 HTML 以收集字段名称、预期值和操作 URL 的列表。
2. 使用相同的字段名称在您自己的网站上重新制作表单。操作 url 应指向您自己的服务器上的处理脚本。此时需要注意的是，站点 B 在加载登录表单页面时是否使用某些特殊令牌字段或 cookie 设置。如果是这种情况，请使用套接字连接并获取站点 B 登录页面的新副本。您需要了解 HTTP 消息标准和正确的请求正文结构把这个关掉。然后，解析检索到的文本以获取要在您自己的页面上使用的令牌字段或 cookie 名称和值。
3. 用户在您的表单上输入站点 B 的用户名和密码。提交时，表单结果将传递到您的处理程序脚本。
4. 您的处理程序脚本使用套接字作为常规 POST 请求连接到站点 B 的操作 url 目标。此 POST 请求包含站点 B 在前几个步骤中为其提供的任何 cookie 和令牌名称/值。您需要再次遵循 HTTP 协议消息结构指南才能实现这一目标。
5. 站点 B 使用您的用户信息进行身份验证。您的处理程序脚本正坐在那里等待响应。
6. 站点 B 响应处理程序脚本。您需要研究站点 B 返回的典型响应，以了解如何解析任何响应文本（并再次学习如何解析 HTTP 消息），包括返回的 cookie 标头。
7. 您的处理程序脚本需要在某处保留一个日志，该日志与用户与站点 B 成功验证后返回的任何 cookie 值相匹配。在以后对站点 B 的任何请求中，再次使用套接字来伪装为用户，将用于 ID 的 cookie 标头/值传递给 ID他们（IE：您的）登录站点 B 的会话。

请记住，您可能希望就您在站点 B 上所做的事情保持开放和诚实的对话，否则您可能承担民事诉讼。

Answer 7

您所描述的场景可能非常棘手甚至不可能。您面临的主要问题是如何将登录凭据发布到站点 B，以便成功登录本身返回的 cookie 最终出现在用户的浏览器中并属于站点 B，以便站点 B 在登录时获取它们。用户实际上导航到那里。

有几个人建议将表单发布到服务器上的 PHP 文件中，并让它在服务器之间进行登录。这个解决方案几乎永远不会起作用。即使站点 B 接受您的服务器-服务器登录（它可能会这样做，因为您可以伪造任何您想要的浏览器），您的网络服务器将获得新的 cookie，并且会话将与之关联的网络服务器的 IP。即使您将 cookie 返回给浏览器，它也会将其保存到您的站点（站点 A），并且当浏览器到达站点 B 时不会将其提交到站点 B，因此用户将保持注销状态 。

因此，您在这里唯一能做的就是在您的服务器上托管其网站的登录表单 这意味着您必须向浏览器发送一个表单，其中包含指向站点 B 的登录表单的操作。这也意味着，每当用户单击登录按钮时，控制权就会转移到站点 B：用户将离开您的站点，您就会失去他。

第二种方法有两个主要的技术问题：一是站点 B 可能有 XSS 防护，实际上可能会阻止您将内容发布到他们的登录页面。另一个问题是，如果您的网站使用 SSL，浏览器会很烦您向其他网站提交表单。这些都不是你自己能够解决的。

唯一干净的解决方案是真正与站点 B 坐下来，制定一些有关通用身份验证或至少是身份验证 API 的计划。您可以尝试表单交叉发布解决方案，但很可能您会遇到您不喜欢的问题。