2

我在业余时间一直在开发一个 webapp。

它主要面向公开发布/消费内容，因此内容有望通过 http 公开查看。它还允许/包含 3rd 方小部件，因此需要 http 访问（许多供应商没有 https 版本，然后在 https 页面上存在 http 的混合内容问题）。由于这个和其他一些业务目标，99% 的网站必须在 http 上可用。

到目前为止，我实施的锁定方案是这样的：

  • 一切都在同一个域上
  • /account 和 /api 下的所有内容都通过 https 和仅限 https 的 cookie 处理。只有这些安全会话 ID 可用于写入或访问个人身份资料。
  • 其他一切都通过 http 和一组单独的 http cookie 处理。这些 cookie 主要用于基于浏览器的 javascript 自定义，而不是用于“写入”或查看敏感内容）

这导致我的问题...

如果有人想在 webapp 上执行书签或社交活动，则需要通过 HTTPS 通道进行 - 使用 HTTPS cookie 等 - 但是浏览器的同源策略将 http 和 https 视为两个不同的服务器。

我正在尝试考虑有效（最好是简单）的方法来允许从 HTTP 内容对 HTTPS 服务器进行 API 调用。我的第一个想法是使用 JSONP，但我需要会话 cookie——而这对我来说是不可见的。

有人有什么建议吗？

4

1 回答 1

3

让我试着理解你的工作流程：你的 HTTP 页面必须调用 HTTPS 服务器，然后它会访问会话 cookie，并且你需要 HTTP 页面可以访问响应，对吗？

一种方法是使用单独的 iframe 来托管与服务器通信的脚本，并让主页和 iframe 使用 HTML5 postMessage进行通信。因此，实现上述工作流程的步骤将是：

  1. 您使用postMessage带有（序列化）请求参数的 iframe；
  2. iframe 的消息回调接收请求，确认它来自您的页面，并向服务器提交 Ajax 请求（传递会话 cookie）；
  3. postMessage使用;接收、序列化并发送到主页面的响应
  4. 主页的消息回调接收响应并对其进行处理。

这应该不难封装在单个函数调用中。这里棘手的部分是上面的粗体片段：如果 iframe 中的脚本没有正确确认请求来自正确的页面，这可能会产生 CSRF 漏洞（恶意页面可能会将您的安全脚本嵌入 iframe，发送请求并且，只要在发生这种情况时对用户进行了身份验证，iframe 就会接受该请求）。

对于这个问题，不幸的是，我几乎没有什么建议。总体而言，在 HTTP 页面中嵌入 HTTPS 内容是一个坏主意，但既然您有理由这样做，您也应该处理安全隐患。

于 2012-05-24T22:31:32.387 回答