通过篡改 POST 有效负载来包含远程文件。真的可以通过 HTTPS 实现吗?

Remote file inclusion by tampering POST payloads. Is it really possible over HTTPS?

以下是我的前端应用程序如何加载其所需的 JS 文件:

页面(在 HTTPS 上)将发送一个 POST 请求,描述应从各种服务器加载哪些 JS 文件。有效负载大致如下所示:

{
   "1": "https://somehost.com/path/first.js",
   "2": "https://someotherhost.com/path/second.js"
}

服务器将收集所有这些JS文件,将它们连接起来并发送回客户端。客户端会将收到的内容放入动态创建的 <script> 标签中。

我们 运行 IBM Appscan 对此进行了研究,令我惊讶的是,Appscan 报告了远程文件包含漏洞,并且该工具能够向 JSON 添加第三个参数,实质上是修改了负载。所以它看起来像这样:

{
   "1": "https://somehost.com/path/first.js",
   "2": "https://someotherhost.com/path/second.js"
   "3": "https://appscan-host/malicious-test.js"
}

我的问题是:

  1. 这真的是一个合理的场景吗?攻击者可以修改受害者浏览器发送的 POST 负载以包含远程恶意脚本吗?我只是无法解决这个问题 - 我确定我在这里遗漏了一些东西。
  2. 鉴于我们的架构可以在 JSON 负载中动态发送 JS 文件 URL,供服务器加载并发送回客户端,我有哪些可能的解决方案来修复此漏洞?
  3. 我阅读了有关使用 HMAC 对请求进行签名的信息,但是如果攻击者找出用于在客户端生成 HMAC 的算法,他只需重新计算 HMAC 并替换发送的 HMAC客户端在篡改 post 有效负载后,对吗?

此外,如果这有帮助,我们使用基于 cookie 的身份验证(Tomcat 服务器,在基于表单的身份验证之后为后续请求设置 JSESSIONID HttpOnly cookie)。

1. Is this really a plausible scenario? That an attacker can modify the POST payload sent by the victim's browser to include a remote malicious script? I just can't wrap my head around this - I'm sure I am missing something here.

您没有注意到恶意用户可能故意向您的服务器提交错误请求。受害者是您的服务器,而不是网站的其他用户。

2. Given that we have an architecture that sends JS file URLs dynamically in a JSON payload for server to load and send back to the client, what possible solutions do I have to fix the vulnerability?

取决于您的具体需求。一种方法可能是将一组可以通过这种方式加载的 JS URL 列入白名单。

3. I read about using an HMAC to sign the requests, but if the attacker figures out the algorithm used for generating the HMAC on the client side, he can just recompute the HMAC and replace the HMAC sent by the client, after tampering the post payload, right?

只有在服务器端计算 HMAC 时,该技术才有效。它不适用于客户端。

我完全同意@duskwuff的回答,只是在这里补充几点(这些是对之前回答中已经提到的内容的补充,而不是替代):

  1. Is this really a plausible scenario? That an attacker can modify the POST payload sent by the victim's browser to include a remote malicious script? I just can't wrap my head around this - I'm sure I am missing something here.

尽管攻击者无法修改(甚至无法以纯文本方式拦截)进行中的 https 请求,但他可以在创建请求时修改请求,可能是通过一些有点 Cross-site scripting 漏洞。因此,受害者 不仅是您的服务器(参见前面的回答),也是您的客户端。

  1. I read about using an HMAC to sign the requests, but if the attacker figures out the algorithm used for generating the HMAC on the client side, he can just recompute the HMAC and replace the HMAC sent by the client, after tampering the post payload, right?

虽然 HMAC 签名是安全的(只要您的密钥是安全的),但我认为在您的客户端代码中包含 HMAC 生成例程对您没有任何好处,因为攻击者可以很容易地看到hmac 算法和您的密钥,并且可以欺骗您的签名。 HMAC 仅在安全且值得信赖的环境(如您自己的服务器)中执行时才有用。

对于您的情况,最好的办法是将合法 URL 列入白名单,并且只从受信任的域下载 js 文件。