问安全跨域认证表格

EN

从您的问题中，听起来您正在试图通过服务器B传递敏感数据，但B不是最终目的地。即使B是目标(或源)，答案仍然是相同的。

这样做的方法是使用HTTPS/TLS/SSL。这将使用A的公共证书对数据进行加密，因此数据只能由A的私钥解密，而只有A才具有。

这也为向客户端验证A的身份提供了额外的好处。A提供用A的私钥签名的证书。只有A的公钥才能正确地解密它，从而证明只有A才能生成该证书(或者有人偷了它，但我们假设情况并非如此)。

编辑：

要做到这一点，让B服务页面但不能读取它的数据，让B提供的web页面使用客户端的Javascript加密数据，并使用A的公钥(可以由B包含在页面中)。即使B拥有A的公钥，它也无法解密由JS加密的数据。它只能传给A。

编辑：

只要在客户端使用A的公钥完成所有加密，除A之外的任何一方都无法读取数据，因为只有A的私钥才能解密。使用这种方法，您可以拥有任意数量的中介人，而不需要任何风险。

*当然，这假设RSA密钥对具有足够的熵和长度，因此被认为是安全的。最少1024位，最好是2048位.

又一次(也是最后一次)编辑:09-5-2013年5月-2013年

很抱歉编辑了这么多，但你的问题让我很困惑。我想我现在明白你在问什么了。

在我之前的文章中，我做了一个重要的假设，即信任服务器B不会恶意尝试获取用户的凭据。我之所以做出这个假设，是因为，正如在评论中所提到的那样，如果B首先具有有限的可信度，允许B收集您的用户凭据是非常不明智和不安全的。此外，我之所以做出这样的假设，是因为使用第三方托管您的web应用程序是一项常见的任务，比如Heroku、Amazon等，他们不会恶意(如果他们这么做，他们将失去一吨生意，他们几乎一无所有。)而且，如果你发现了违反安全的行为，你就得找个人负责。因此，它们可以被信任，否则您一开始就不会使用它们)。我现在假设您没有使用像它们这样的第三方源，因为显然是这样的。

如果B可能具有潜在的恶意，那么无论您如何处理客户端代码，B都可以更改它并拦截凭据。只要可以信任B不修改客户端代码，那么我以前的建议就会奏效。然而，鉴于这一新的信息，B是有限的可信度，这将是不明智的执行我以前的建议。

通过不受信任的第三方对用户进行服务身份验证是一项非常危险的工作，PayPal用于构建API的金额表明了这一点。但是，如果必须这样做，则需要非常小心，并考虑实现一种类似于PayPal的解决方案。

如果你必须通过第三方，那么一个类似于上面评论中提到的@halfer的解决方案就是要走的路，IMO。

也许您应该单击B中的某个内容，它重定向到A，从您的站点获得用户权限，并使用身份验证令牌重定向回B。这样做的好处是，您不会鼓励用户在他们不应该绝对信任的站点中输入他们的主密码。

让用户使用HTTPS/TLS/SSL重定向到您的站点。这将保护用户的凭据，并向用户验证您的身份，这样他们就不太可能受到吞咽攻击。然后，您可以向第三方提供一个足够随机的令牌，以用作身份验证。

然而，请理解，即使有了这一解决办法，仍然存在很大的风险。如果B想攻击您的用户，B仍然可以简单地直接询问他们的登录凭据，从而很容易地欺骗他们中的一个百分比。这可能会对他们中的大多数人不利，因为他们不懂安全。

如果B不可信，那么我的专业建议是不要这样做。