Problem with sessionToken handling

[bwerther]

Hi,

I've been trying to sign an 'execute-api' request to API Gateway using temporary IAM credentials (using 1.4.0). It wasn't working, so I dug into the code to see how the sessionToken is being used. I tried with both signSessionToken set to true and false, but neither worked. I noticed that if it was set to true, you'd delete query["X-Amz-Security-Token"] (line 227) before building the query string. Commenting out this line (so that the sessionToken would still appear in the query string) made it work.

-Ben

[beetahnator]

I just ran into the same issue trying to generate an signed STS request.

Chain of events went like this:

1. Tried with just key, secret, and sessionToken
2. Found this GH issue and added signSessionToken; X-Amz-Security-Token is gone from the generated url
3. Comment out line 227 as @bwerther suggests, X-Amz-Security-Token is back in the signed url and I finally get a valid signature.

I'm not exactly sure how the session token signing is supposed to be handled, on lines 193-197 we add it before generating signatures.

  // when a session token must be "signed" into the canonical request
  // (needed for some services, such as s3)
  if (options.sessionToken && options.signSessionToken) {
    query["X-Amz-Security-Token"] = options.sessionToken;
  }

But then on line 222-228 it gets removed from the params.

  // when a session token must NOT be "signed" into the canonical request
  // (needed for some services, such as IoT)
  if (options.sessionToken && !options.signSessionToken) {
    query["X-Amz-Security-Token"] = options.sessionToken;
  } else {
    delete query["X-Amz-Security-Token"];
  }

@slaskis would you be able to chime in here?

I'd love to get a fix out so I can switch to using the upstream repo vs my personal fork.

[zenchicken]

I could be mistaken, but I think line 224 is incorrect. Except in the case of a shared secret, all other parts of the signature input must be visible to both sides in order to calculate the same signature. Line 224 would omit the X-Amz-Security-Token query param from the AWS side even though that value was included during the signature calc at the browser side. The mismatch would cause both sides to calculate mismatched signatures. The line probably needs to read:

if (options.sessionToken && options.signSessionToken) {

[trademark18]

Maybe related: I am using the package in a Lambda to create a presigned URL for S3. I'm not authenticating with the same credentials as the Lambda is using (which is what is in the environment vars), but rather using an access key and secret key that are returned in a DB query. In order to make it work I had to delete process.env.AWS_SESSION_TOKEN; to get it to work.

For reference for others, this is what worked:

delete process.env.AWS_SESSION_TOKEN;

let url = v4.createPresignedS3URL(
	'Foldername/filename.png', 
	{
		key: config['AwsAccessKey'],
		secret: config['AwsSecretKey'],
		bucket: process.env.bucketName
	}
);