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

Question

Here is how my front-end application loads its required JS files:

A page (on HTTPS) will send a POST request describing what JS files should be loaded from various servers. The payload will look roughly like this:

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

The server will collect all these JS files, concatenate them and send back to the client. Client will place the received contents within a dynamically created <script> tag.

We ran IBM Appscan on this and to my surprise, Appscan reported Remote File Inclusion vulnerability and the tool was able to add a 3rd parameter to the JSON, essentially modifying the payload. So it looked something like this:

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

My questions are:

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?
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?

Also, if this helps in anyway, we use cookie based authentication (Tomcat server, sets JSESSIONID HttpOnly cookie after form based authentication for subsequent requests).

Answer 1

I totally agree with @duskwuff's answer, just adding a few more points here (these are in addition and not replacement to what is already mentioned in the previous answer):

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.

Although the attacker cannot modify (or even intercept in plain-text) an in-flight https request, he can modify the request at the time of creation, possibly through some kind of Cross-site scripting vulnerability. Thus, the victim is not only your server(see previous answer) but also your client.

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?

Although, HMAC signatures are secured (as long as your key is safe), I don't think including an HMAC generation routine in your client-side code will do any good to you as the attacker can easily see the hmac algorithm and your keys and can spoof your signatures. HMAC is only good if performed in a secure and trust-worthy environment (like your own server).

In your case, the best thing would be to whitelist legitimate URLs and only download js files from trusted domains.