0

以下是我的前端应用程序加载所需 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，正确的？

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

4

2 回答 2

1

1. 这真的是一个合理的场景吗？攻击者可以修改受害者浏览器发送的 POST 有效负载以包含远程恶意脚本？我只是无法解决这个问题-我确定我在这里遗漏了一些东西。

您缺少的是恶意用户可能故意向您的服务器提交错误的请求。受害者是您的服务器，而不是该站点的其他用户。

2. 鉴于我们的架构可以在 JSON 有效负载中动态发送 JS 文件 URL 以供服务器加载并发送回客户端，我有哪些可能的解决方案来修复该漏洞？

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

3. 我读到过使用 HMAC 对请求进行签名，但如果攻击者弄清楚客户端生成 HMAC 的算法，他可以在篡改帖子后重新计算 HMAC 并替换客户端发送的 HMAC有效载荷，对吧？

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

于 2017-06-11T05:47:31.223 回答
1

我完全同意@duskwuff 的回答，只是在这里添加了几点（这些是对前面回答中已经提到的内容的补充，而不是替代）：

  1. 这真的是一个合理的场景吗？攻击者可以修改受害者浏览器发送的 POST 有效负载以包含远程恶意脚本？我只是无法解决这个问题-我确定我在这里遗漏了一些东西。

尽管攻击者无法修改（甚至以纯文本形式拦截）正在进行的 https 请求，但他可以在创建时修改请求，可能是通过某种跨站点脚本漏洞。因此，受害者不仅是您的服务器（参见前面的答案），而且还是您的客户端。

  1. 我读到过使用 HMAC 对请求进行签名，但如果攻击者弄清楚了用于在客户端生成 HMAC 的算法，他可以在篡改后有效负载后重新计算 HMAC 并替换客户端发送的 HMAC，正确的？

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

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

于 2017-06-11T06:09:40.040 回答