Secure Link Expires - URL Signing

[anish10dec]

Let me explain the complete implementation methodology and problem
statement

URL to be protected 
http://site.media.com/mediafiles/movie.m3u8

We are generating token on application/client side to send it along with
request so that content is delivered by server only to authorized apps.

Token Generation Methodology on App/Client

expire = Current Epoch Time on App/Client + 600 ( 600 so that URL will be
valid for 10 mins)
uri = mediafiles/movie.m3u8
secret = secretkey

On Client , MD5 Function is used to generate token by using three above
defined values
token = MD5 Hash ( secret, uri, expire)

Client passes generated token along with expiry time with URL
http://site.media.com/mediafiles/movie.m3u8?token={generated
value}&expire={value in variable expire}


Token Validation on Server
Token and Expire is captured and passed through secure link module 

location / {

secure_link $arg_token,$arg_expire; 
secure_link_md5  "secretkey$uri$arg_expire";

//If token generated here matches with token passed in request , content is
delivered 
if ($secure_link = "") {return 405;}  // token doesn't match 

if ($secure_link = "0") {return 410;} 
//If value in arg_expire time is greater current epoch time of server ,
content is delivered . 
Since arg_expire has epoch time of device + 600 sec so on server it will be
success. If someone tries to access the content using same URL after 600 sec
, time on server will be greater than time send in arg_expire and thus
request will be denied.


Problem Statement
Someone changes the time on his client device to say some future date and
time. In this case same app will generate the token with above mention
methodolgy on client and send it along with request to server.
Server will generate the token at its end using all the values along with
expire time send in URL request ( note here expire time is generated using
future date on device)
So token will match and 1st check will be successful . 
In 2nd check since arg_expire has epoch time of future date + 600 sec which
will be obviously greater than current epcoh time of server and  request
will be successfully delivered.
Anyone can use same token and extended epoch time with request for that
period of time for which future date was set on device.

Hopefully now its explainatory . 
Please let know if there is a way to protect the content in this scenario.

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,278063,278088#msg-278088