Disappearing header issue

Making Packs
1

Took me a while to figure out this bug

  • Use the CustomHeaderToken authentication
  • Set connectionRequirement to None
  • Try to set the header manually
  • Header is gone from request

image

Working minimal example: (Pack 26831 if you can access that)

import * as coda from "@codahq/packs-sdk";
export const pack = coda.newPack();

pack.addNetworkDomain("google.com");

pack.setUserAuthentication({
  type: coda.AuthenticationType.CustomHeaderToken,
  headerName: "Authorization",  // <----------------------------------------------------------
});

pack.addFormula({
  connectionRequirement: coda.ConnectionRequirement.None,  // <-------------------------------
  name: "X",
  description: "check the request",
  parameters: [],
  resultType: coda.ValueType.String,
  execute: async function ([], context) {
    let response = await context.fetcher.fetch({
      headers: {
        "Authorization": "this value will be removed",  // <----------------------------------
        "Content-Type": "application/json",
      },
      method: "GET",
      url: "https://google.com",
    });
    return response.body;
  },
});
2

Hi @Rickard_Abraham - This is actually “working as intended”, although I’m realizing now we haven’t documented it anywhere. When you set an authentication type we prevent you from feeding other values into that same location. This is to help prevent cases where the Pack accesses user data and then sends it to an account they control with hard-coded credentials.

3

Oh okay, thanks for your response! I’m afraid I don’t follow the logic though. Why would a malicious actor even bother with setting up the auth if they have hard coded headers

If they want the user to think they’ve authed they could just set the headerName to a random word :sweat_smile:

But I understand it’s better to be safe than sorry when it comes to attack vectors. Documentation or even an additional check in your pack validator would’ve been great to catch this early

4

Something we’ve worked hard to prevent in the Packs platform is “data exfiltration”. In other words, where the Pack reads user data and stashes it away somewhere the attacker can access later. This is why for instance we only allow one network domain, so you can’t retrieve data from the user’s account and then send a copy to your private server.

However with some APIs it in theory could be possible to retrieve information from the user’s account using their credentials, and then save a copy of it to attacker’s account in the same domain using their credentials.

The behavior your witnessed is in place to help prevent that case. Once you declare a method of transmitting user credentials, we don’t let you manually set that same method (header, query param, etc) to some hard-coded value.

5

Oh okay I think it clicked for me now, thanks! That sounds like a tricky thing to deal with and it seems like the right choice to prevent changing the header