【问题标题】:How to validate a referring server. ($_SERVER["HTTP_REFERER"])如何验证引用服务器。 ($_SERVER["HTTP_REFERER"])
【发布时间】:2013-03-05 00:17:01
【问题描述】:

当这些服务器通过我们的测试时,我客户的网站会按 IP 向他们的客户提供证书。此认证仅适用于经过测试的 IP。因此,我们需要成为提供证书的人,以便我们可以验证显示我们证书的站点是否确实经过了我们的测试。因此,当客户的用户单击证书的链接时,他们可以相信该站点确实经过了我们的测试(该站点没有由未经我们测试但声称是的另一台服务器提供服务) .

用户通过如下所示的链接被定向到我们的网站:

siteB.com/certificate.php?companyid=1234&serverid=4321

流程简化:

  • 用户在站点 A 上
  • 用户单击指向我的站点(站点 B)的链接以查看站点 A 的证书。
  • 我的站点 B 需要验证确实是站点 A 正在尝试显示站点 A 获得的证书。

最初,我认为 $_SERVER 变量可能有一个值来指示引用服务器是谁,但我收到的发布问题的答案表明,虽然该信息存储在 $_SERVER["HTTP_REFERER"] ,不可靠(插件或用户可能会修改此值)。

由于我不能依赖它,我需要另一种方法来验证引荐服务器是他们声称的那个人。我考虑使用一次性使用令牌,但是有效的服务器可以简单地将令牌循环到客户拥有的其他服务器(尚未经过测试),客户可以通过这种方式声称他们的任意数量的服务器都经过认证我们只需支付一次测试的费用(以及损坏证书的完整性)。

我想知道这个问题是否不可能制定一个万无一失的解决方案,并且可以做的最好的事情是混淆不受控制的端点(客户的服务器)发布密钥以表明他们是证书的用途(例如,狡猾的客户必须阅读一些混乱的混淆 javascript,或反汇编闭源客户端程序以欺骗系统)。

到目前为止,我的想法是这样的(这很糟糕):


我需要制作一个闭源程序来运行客户端,可能通过Native Client 在单击客户网站(站点 A)上的证书链接时启动,这将首先使用我的站点(站点 B),然后打开与站点 A 的服务器、站点 B 的服务器和用户的 3 路通信线路,其中站点 B 将验证站点 A 是他们所说的那个人,然后返回给用户证书或说明无法加载证书的原因的错误消息(例如连接超时)。

站点 B 上向用户 NaCl 程序开放流的脚本将 use curl 获取站点 A 的服务器的 IP 地址并进行验证。


对我来说,这是一个非常粗糙的解决方案(如果它甚至是一个解决方案),虽然大多数用户不关心查看某人的证书,但让关心的用户经历了很多麻烦(安装和运行 NaCl程序)只是看证书简直是疯了。

这感觉有点像一个愚蠢的问题,但将其作为闪存运行会与运行 NaCl 程序一样安全/不安全吗?

当然,有更好的方法来做这一切......

【问题讨论】:

    标签: php flash security networking google-nativeclient


    【解决方案1】:

    您最好的选择是信任 REFERER 或使用 ORIGIN 标头(您需要设置一个 AJAX 脚本,该脚本可以放入站点以使用 ORIGIN)。

    您的服务器接收到的任何内容都可以很容易地被 客户端 计算机欺骗,但不能被他们正在访问的 服务器 欺骗(未经客户端同意)。由于您的服务似乎是为客户服务的,因此他们没有理由伪造凭据。您可能会遇到某些插件和代理的潜在问题,但您的警告消息可以解释这一点。

    没有封闭源代码的客户端代码。任何人都可以简单地对其进行反编译或模拟运行时,因此您不会获得额外的安全性。

    公钥/私钥也不起作用(您的站点生成要编码的东西,相关服务器必须使用其私钥对其进行编码,客户端使用公钥对其进行检查)。它们仍然容易受到相同问题的影响:虚假站点可以将请求连同完美复制的标头一起转发到真实站点进行处理。

    要记住的事情:

    • AJAX 允许 client 和/或 server 修改标头,但现代浏览器保证的 ORIGIN 标头除外(但可以通过 客户有一些工作)
    • 任何标准的 URL 请求都有浏览器生成的所有标头,因此可以信任它们(只能由客户端更改)
    • 发送到客户端计算机的任何代码或机密(即使经过编译、混淆或其他)都应视为公开的。
    • 任何不是来自浏览器的请求都可以在各个方面被伪造,除了 IP 地址(甚至可以代理)

    【讨论】:

    • 太棒了!我不知道 ORIGIN 标头。简单地使用 ajax 验证并重定向到证书页面的 URL,在查询字符串中使用一次性使用令牌(在验证响应中提供)听起来很完美。就像您说的那样,客户端没有理由要更改此标头值。谢谢,戴夫!
    • 酷!!!如果您需要任何编程帮助,请告诉我。我很想这样做!哈哈
    【解决方案2】:

    我的想法.. 如果可能的话,让证书颁发服务器根据引用服务器的名称创建一个带有 hash 的 cookie,并根据另一组动态生成的标准创建一个 salt,但可预测方式,例如使用用户的 IP 地址加上星期几,并可能输入小时数或当前分钟数(标准上的时间段太短会导致一些误报身份验证失败,所以要小心)。然后,当用户到达您的站点时,读取 cookie 的哈希值并将其与从$_SERVER[“HTTP_REFERER”] 和预先建立的标准生成的哈希值进行比较。这样做的缺点是,如果引用服务器想成为小白,他们可以发布安全算法。

    另一个可能更安全的选择是创建一个 JavaScript 应用程序,您将其提供给引用服务器,该应用程序向您的服务器发送AJAX 调用,然后您的服务器根据我上面提到的相同类型的标准返回一个哈希值。然后由引用服务器根据您返回的AJAX 哈希设置 cookie,当他们访问您的站点时,它会以与我之前提到的相同的方式进行检查。但由于所有处理都发生在您的服务器上,因此它是完全安全的。听起来是个很酷的项目,祝你好运。

    【讨论】:

    • 这行不通。假设用户访问了一个虚假站点,虚假站点的服务器直接向好站点的服务器(CURL 或其他)发送请求,提取 cookie 信息,并将其连同其恶意内容一起转发给客户端。假网站现在有一个“好”的 cookie,你使用的任何加密/散列都是没有实际意义的。
    • 此外,AJAX 理念(请记住,唯一安全的 AJAX 标头是 ORIGIN)并不比在标准 URL 中使用 REFERER 标头更安全。然而,它可能对代理和其他可能试图隐藏引荐来源网址的东西更健壮(使其在更多情况下工作,使其或多或少安全)。
    猜你喜欢
    • 2012-09-27
    • 1970-01-01
    • 2012-04-13
    • 1970-01-01
    • 2016-03-03
    • 1970-01-01
    • 2017-04-09
    • 2023-03-31
    • 1970-01-01
    相关资源
    最近更新 更多