CODEWITHSUNDEEP
amazon-web-servicesamazon-s3pre-signed-url
kgalli
kgalli

Reputation: 259

What is the "aws_security_token" used for

I want to use pre-signed URLs with AWS S3. What I noticed is that pre-signed URL include the aws_access_key_id and the aws_security_token.

From my understanding the aws_security_token is part of the URL because I'm using temporary security credentials and it is necessary for signing the URL properly.

But is it fine to give the URL to let's say a frontend client to download an image? The aws_security_token is part of the URL (not encrypted). I'm concerned about security and I was not able to figure out what the purpose of the token is. And what an attacker can do with my aws_access_key_id and the aws_security_token.

Upvotes: 3

Views: 7767

Answers (2)

Bruno Bronosky
Bruno Bronosky

Reputation: 70409

In 2014 Amazon switched from AWS_SECURITY_TOKEN to AWS_SESSION_TOKEN and you should favor the latter also. Many projects still either set or check both, but It's been 5 years. I think we can let it go.

The aws sts assume-role command only returns SessionToken so, I am only supporting that in code I write.

Here is an example of using the aws cli:

function mfa_serial(){
    aws configure get --profile=$1 mfa_serial
}

function role_arn(){
    aws configure get --profile=$1 role_arn
}

function assrole(){
    aws sts assume-role                         \
        --role-arn          "$(role_arn   $1)"  \
        --serial-number     "$(mfa_serial $1)"  \
        --token-code        "$(mfa)"            \
        --role-session-name "$( ( id -un; date +-%Y-%m-%d+%H.%M.%S ) | tr -d '\n' )"
}

assrole development

Here is the output:

{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROAIWL33TL33TL33TL33:brunobronosky",
        "Arn": "arn:aws:sts::485548554855:assumed-role/allow-full-access-from-other-accounts/brunobronosky"
    },
    "Credentials": {
        "SecretAccessKey": "L33TL33TL33TL33TL33TL33TL33TL33TL33TL33T",
        "SessionToken": "L33TL33TL33TEI///////////L33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33Tm9/TL33TL33TL33TL33T/TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33Tz9/TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TS/TL33TL33TL33TL33TL33TL33TL33TL33TL33T/TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33TL33Tos/TL33TL33TL33TL33TL33TL33TL33T/A==",
        "Expiration": "2019-11-01T00:00:00Z",
        "AccessKeyId": "ASIAL33TL33TL33TL33T"
    }
}

Upvotes: 7

Michael - sqlbot
Michael - sqlbot

Reputation: 179194

Yes, the aws_access_key_id and aws_security_token (if present) are considered safe to expose.

To be able to do any harm, and attacker would theoretically need to reverse-engineer the third component, the aws access key secret, based on the request parameters and signature, so that they could generate valid alternate signatures for alternate requests.

If that were possible, the attacker could then perform any action that the temporary credentials have the authority to do -- however -- this would involve reverse-engineering multiple rounds of HMAC-SHA-256, and is considered computationally infeasible.

Additionally, when using temporary credentials (which is where you'd see aws_security_token), the credentials are valid only for a short time, anyway -- so even if reverse-engineering were practical, it would have to be done in an impractically short period of time.

The security token itself -- presumably -- is a signed and encrypted message describing the permissions that accompany the temporary access key id and secret, facilitating decentralization of the authorization decisions based on the tokens, within AWS. Regardless of its actual content (which doesn't appear to be documented), it isn't independently useful without the accompanying temporary access key id and secret -- and the secret is not disclosed in the signed URL and can't feasibly be reverse-engineered, as discussed above. The temporary access key id and secret, conversely, are useless without the token.

Upvotes: 4

Related Questions