Bug in secure iparam substitution in request template

Hi @satwik,

I’ve been using the request template for a while and have noticed that the substitution of header value with non-secure iparams and context works well.

Whereas, substitution with secure iparam does not work.

Here’s a screenshot of the documentation where it is mentioned that secure iparam substitution is allowed in request header values.

Here’s my sample code in requests.json

"requestTemplate": {
        "schema": {
            "method": "POST",
            "protocol": "https",
            "host": "<%= iparam.secureConfigs.host %>",
            "path": "<%= context.path %>",
            "headers": {
                "Authorization": "<%= iparam.secureConfigs.authorization %>",
                "Content-Type": "<%= context.contentType %>"
            }
        }
    },

This feature needs to work as advertised for security reasons.

Please have a look.

Regards,
Arun Rajkumar

cc: @Asif @Raviraj @Saif @kaustavdm @zach_jones_noel

Hi @arunrajkumar235, hope everything’s well.

Can I ask from where you are trying to invoke the request template that you have mentioned? Are you doing it from the iparams page in gallery?

Hey @arunrajkumar235,

To add on to what @Sudarsana_Raghavan mentioned, in the iparams page we don’t allow secure or non secure iparam values instead you would have to use context.

Take a look at the GitHub repo for the sample app which demonstrates this.

I fully understand that in the iparams page in gallery only context substitution works.

The bug I’ve reported happens in the Ticket Sidebar placeholder.

Hi @zach_jones_noel ,

I went through the sample code. Largely, it looks fine to me.

But, I noticed the usage of iparams. (plural of iparam).


Here’s the link to the file in the screenshot.

I’ve only been using the singular form iparam. and am guessing that is the correct way to use it.

Regards,
Arun Rajkumar

Hi @arunrajkumar235,

Yes, iparam is the correct way of working with it. Thanks for getting this to our attention. We will recheck and update it.

About the ticket sidebar placeholder app, can you share the app so that we can understand which Request Template and how the substitutions are made so that we can test it better.

Hi @arunrajkumar235,

Thanks for pointing that out in the sample app. As @zach_jones_noel mentioned, could you please share the app so that we can check this from our end? I made a sample request from the ticket side_bar and I am able to substitute secure iparams in the headers.

Hi @Sudarsana_Raghavan,

The codebase is quite complicated, involving Ember and React.
So, I made a video explaining how I was able to reproduce the bug.

1 Like

The above video was taken during localhost development.

I then tried publishing the app as a custom app and here’s the error response I get while calling the request template.

1 Like

Thanks for taking the time to record videos in detail, Arun. We will take a look and get back to you on updates by today.

1 Like

Hey @arunrajkumar235,

I took a look at the recording, it was clear - thank you for that.

I’m pasting the requestTemplate you are trying to invoke:

"requestTemplatePOSTi0": {
          "schema":
              "method": "POST",
              "protocol": "https",
              "host": "<%= iparam.secureConfigs.i0.host %>",
              "path": "<%= context.path %>",
              "headers": {
                  "Authorization": "<%= iparam.secureConfigs.i0.authorization %>",
                  "Content-Type": "<%= context.contentType %>"
              }
         }
}            

I observed that you are trying to access a secure iparam in the host <%= iparam. secureConfigs.i0.host %>". I missed this from your snippet earlier - from the documentation, we allow only non-secure iparams in the host. I suspect that this might be the reason for the issue you are facing. Could you please try fetching the host from a non-secure iparam and let us know if you still face the template substitution issue?

1 Like

@Sudarsana_Raghavan , thank you so much for you time. I can confirm that this works. I made the host accessible through a non-secure iparam.

Just out of curiosity, why was the decision taken to not allow secure-iparam substitution for host?

1 Like

We wanted to avoid the loophole where an intruder uses the secure iparam to replace host that can throw an error like : ‘Unable to resolve host <secure_iparam_value>’ and leak the value. So, we went ahead with this.

But, an intruder cannot modify a secure iparam. It is defined in requests.json. The intruder would never have access to that file.

This topic was automatically closed 6 days after the last reply. New replies are no longer allowed.