S3 Uploading pre-signed URL with signature v4, Content Disposition causes signature mismatch

[CanGokdere]

I am currently using pre-signed uploading to directly upload from browser to s3. I can upload with no problems when I do not set the content disposition in options, for instance:

var s3upload = new AWS.S3({
signatureVersion: 'v4',
accessKeyId: process.env.S3_UPLOAD_CLIENT_KEY,
secretAccessKey: process.env.S3_UPLOAD_CLIENT_SECRET,
});
var baseOptions = {
Bucket: process.env.S3_BUCKET,
ACL: 'public-read',
Key: uuidv4(),
}

This works fine, http request:

This also works fine when I set encryption

var baseOptions = {
Bucket: process.env.S3_BUCKET,
ACL: 'public-read',
Key: uuidv4(),
ServerSideEncryption: 'AES256'
}

But if I add content disposition to options, I always get Signature mismatch

var baseOptions = {
Bucket: process.env.S3_BUCKET,
ACL: 'public-read',
Key: uuidv4(),
ContentDisposition: 'attachment',
ServerSideEncryption: 'AES256'
}

I get the following response:
<?xml version="1.0" encoding="UTF-8"?> <Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message>

What is the problem and how can I fix it ?

[jeskew]

Hi @CanGokdere,

It looks like we're hoisting headers to the query string after the request has already been signed, which invalidates a V4 signature. This appears to be permitted in V2 presigned URLs, but we'll need to modify the presigner to properly account for SigV4's requirements.

[CanGokdere]

Hello @jeskew,
I have updated the sdk but my issue with Content Disposition still persists. I have tested by using headers and also without headers and only using pre-signed url and query parameters. If I want to include content disposition in presigned url it still causes signature mismatch.

[jeskew]

Hi @CanGokdere,

I was able to successfully use pre-signed URLs to execute a PutObject operation using the following code that relies on the master branch of the SDK (the update has not yet been included in a release):

const AWS = require('aws-sdk');
const uuidv4 = require('uuid/v4');
const https = require('https');
const url = require('url');
const s3 = new AWS.S3({
    region: 'us-west-2',
    signatureVersion: 'v4'
});
const presigned = s3.getSignedUrl('putObject', {
    Bucket: bucketName,
    Key: uuidv4(),
    ContentDisposition: 'Attachment'
});
console.log(presigned);
const options = url.parse(presigned);
options.method = 'PUT';
options.headers = {'content-disposition': 'Attachment'};

const stream = https.request(options);
stream.on('response', (res) => {
    console.log(res.statusCode);
    res.pipe(process.stdout);
});

stream.end('body');

Please note that you can add a Content-Disposition header after signing.

[vladholubiev]

@jeskew thanks for the fix! I had the same problem after I added X-Ray to my Lambda which generated a signed link for getObject (downloading). So I didn't add extra headers from client-side, but look slike Lambda adds extra query string parameters like xray-trace-id or smth like that. After updating to 2.156.0 the signature is valid again.

But it's a pity Lambda environment has still old 2.129.0 version, so people need to deploy extra dependencies.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.