Question

以下是我的前端应用程序加载其所需的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"
}

我的问题是：

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

Answer 1

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

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

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

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

3。我读到了使用HMAC对请求进行签名，但是如果攻击者在客户端找出用于生成HMAC的算法，他可以在篡改后有效载荷后重新计算HMAC并替换客户端发送的HMAC，正确？

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

Answer 2

我完全同意@ duskwuff的回答，只是在这里添加了几点（这些是另外的，而不是替换上一个答案中已经提到的内容）：

这真的是一个看似合理的情景吗？攻击者可以修改受害者浏览器发送的POST有效负载以包含远程恶意脚本吗？我无法绕过这个 - 我相信我在这里错过了一些东西。

虽然攻击者无法修改（或甚至以明文方式拦截）正在进行的https请求，但可以在创建时修改请求，可能是通过某种{{3漏洞。因此，受害者不仅是您的服务器（请参阅上一个答案），也是您的客户。

我读到了使用HMAC对请求进行签名，但如果攻击者在客户端找出用于生成HMAC的算法，他可以在篡改后重新计算HMAC并替换客户端发送的HMAC。有效载荷，对吗？

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

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