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:

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

score 1 · Answer 1 · 2017-06-11T06:35:44.783

1

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.

What you're missing is that a malicious user could intentionally submit a bad request to your server. The victim is your server, not another user of the site.

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?

Depends on your specific needs. One approach may be to whitelist a set of JS URLs that can be loaded this way.

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?

That technique would only work if the HMAC were computed on the server side. It's not applicable on the client side.

edited Jun 11 '17 at 06:35

answered Jun 11 '17 at 05:47

Thanks @duskwuff and @riyaz-ali! Forgot to mention this in my question, but white-listing JS URLs is not applicable in our scenario because the server-side component that works on the JSON payload is a generic piece of software and it is kind of made to work with any application like ours. But I understand the vulnerability better now - still thinking what can be done to avoid this. – rkrishnan Jun 11 '17 at 06:58
1

Which backend are you using? Depending on the backend it may (or may not be) possible to pass your request through multiple handlers (middlewares)....For e.g. in nodejs (express) you could simply load a whitelisting middleware before your actual middleware and sanitize the json payload..... I guess it should be possible to do this on majority of the backends... – riyaz-ali Jun 11 '17 at 07:12
Hmmm. We use tomcat. May be we can use a servlet filter to intercept everything before we allow the request to hit this generic component. Although that means quite a bit of config changes and complex custom builds in our specific case. But looks like that's the only option. Thanks! – rkrishnan Jun 11 '17 at 07:21

score 1 · Accepted Answer · answered Jun 11 '17 at 06:09

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):

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.

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.

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

2 Answers2