SAS URI Token Encryption


  • I have a scenario in our application that we are passing SAS URI token for accessing files stored in cloud storage for users. There might be possibility that user might capture SAS URI in fiddler or any other tool and can tamper with its parameters and have unauthorised access to the storage.

    As per my findings SAS URI is already secure and provides access to cloud storage on validating signatures as per azure. But what if user tampers with expiry date/time specified in SAS URI. Will he/she be allowed to access storage ?

    Do we have some mechanism supported by azure regarding encrypting and decrypting SAS URI so that we can pass encrypted SAS and decrypt at azure end ?

    Friday, October 21, 2016 7:30 AM

All replies

  • Hello,

    We are checking on the query and would get back to you soon on this.

    Apologize for the inconvenience and appreciate your time and patience in this matter.




    Saturday, October 22, 2016 6:20 AM
  • SAS URI is signed with one of two storage account keys. Modifying the expiry date/time will result in the token failing the integrity check - and effectively render the SAS URI invalid


    Saturday, October 22, 2016 11:08 AM
  • Hi Marcin,

    As per your above comments you mean to say if user tampers SAS URI with any of its parameters then Azure will perform integrity check before giving access to blob container.

    I have a SAS URI which is active till 11th Nov 2016. I have changed its expiry date to previous date say (1st Oct 2016) so that it should not allow me to access files. But still in some PC it is allowing me to download/access file and in some it is giving invalid URI message.

    So could you please give some highlights on above scenario why this is happening or is it some bug ?


    Prakhar Tamrakar

    Monday, October 24, 2016 6:30 AM
  • Hi Prakar,

    Can you clarify what specifically you mean by "I have changed its expiry date to previous date say (1st Oct 2016) so that it should not allow me to access files" ?

    Does this mean that you are using a properly signed SAS token with the expiration date in the past (i.e. you modified the expiration date and regenerated the token) - or did you simply modify the expiry date within the existing SAS token (therefore compromising its integrity and rendering it invalid)?

    Either of these should effectively prevent you from accessing the corresponding blob, but the error message should differ. Can you post the message you are getting?


    Monday, October 24, 2016 12:15 PM
  • Hi,

    Are you trying this out with different dates using the same browser? I've had caching problems with IE, and find it I try it with a valid date/time, then try it with an invalid date/time, sometimes the invalid date/time works because it's really showing the cached entry. Try opening an in-private browsing window each time you want to view a URL and see if that helps.


    Sr. Content Developer at Microsoft

    Friday, October 28, 2016 5:59 AM
  • There is an argument that is part of the SAS called something like "sig". This is an encrypted signature. This is created using all of the information specified for the parameters. When the storage service is called to access an SAS URL, the service takes all of the parameters specified and creates the encrypted signature and checks this against the encrypted signature sent in as part of the URL. If the user has modified any of the arguments, the signatures won't match, and the request will not authenticate.

    Hope this helps!


    Sr. Content Developer at Microsoft

    Friday, October 28, 2016 6:01 AM