anish10dec
Secure Link Expires - URL Signing
January 10, 2018 09:20AM
URL Signing by Secure Link MD5 , restricts the client from accessing the
secured object for limited time using below module

Exp time is sent as query parameter from client device

secure_link $arg_hash,$arg_exp;
secure_link_md5 "secret$arg_exp";
if ($secure_link = "") {return 405;}
if ($secure_link = "0") {return 410;}

Here problem is that if expiry time i.e exp send from client is less than
server time nginx module returns 410 .

But if some client changes the time of device to some future date and
request for object in that case also object will be delivered as client time
will be greater than server time.
Is there a way to restrict the request, by secure link module, to future
time so that for example object should be accessible only for 1 hour time
duration from current time.
Please suggest

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

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Francis Daly
Re: Secure Link Expires - URL Signing
January 10, 2018 09:50AM
On Wed, Jan 10, 2018 at 03:15:05AM -0500, anish10dec wrote:
> URL Signing by Secure Link MD5 , restricts the client from accessing the
> secured object for limited time using below module

It can, if you configure it to.

> Exp time is sent as query parameter from client device
>
> secure_link $arg_hash,$arg_exp;
> secure_link_md5 "secret$arg_exp";

http://nginx.org/r/secure_link_md5 says

"""
The expression should contain the secured part of a link (resource) and
a secret ingredient. If the link has a limited lifetime, the expression
should also contain $secure_link_expires.
"""

You appear to have included only one of the three pieces.

> Is there a way to restrict the request, by secure link module, to future
> time so that for example object should be accessible only for 1 hour time
> duration from current time.

Yes.

Create the link and do the configuration like the documentation suggests.

If it still does not work for you, can you show all of the steps that
you take to secure one specific url? That might make it clear where the
problem first appears. (Maybe the documentation needs changing.)

f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
anish10dec
Re: Secure Link Expires - URL Signing
January 10, 2018 07:40PM
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

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Richard Stanway via nginx
Re: Secure Link Expires - URL Signing
January 10, 2018 07:50PM
Only the server should be generating the tokens, if the client knows the
secret it can do whatever it wants.

On Wed, Jan 10, 2018 at 10:32 AM, anish10dec <[email protected]>
wrote:

> 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
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Francis Daly
Re: Secure Link Expires - URL Signing
January 11, 2018 12:10AM
On Wed, Jan 10, 2018 at 01:32:00PM -0500, anish10dec wrote:

Hi there,

> 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.

There's your design problem.

Don't generate the token on the client side. Have the client do whatever
it takes to convince the server that it is authorised, and have it ask
for a current link to the movie.m3u8 content.

Then the server uses the server-secret and whatever other things are
relevant to create a secure_link url, possibly including an expiry time
based on the server-clock, are returns that url to this client.

Then when any client tries to access that url after the server-clock
expiry, they will fail. And if any client tries to access that url before
the expiry time, it will be allowed only if the secure_link matches -- if
it includes something like REMOTE_USER or a $cookie that was only given to
one client, then only something with the matching values will succeed; if
it was just based on things within the url, then every thing will succeed.

> Please let know if there is a way to protect the content in this scenario.

No.

In your scenario, the client decides the expiry time, and creates a url
that the server will honour until then.

(And it can create a new url that will expire a day later, and the server
will honour that too.)

Anyone who requests that url before that expiry time will be given
the content.

So in your scenario, you would probably have to write your own
securish_link module which checks that the expiry time is in the future,
but not too far in the future. And then decide how much slop to allow,
in case someone has the clock wrong on their client.

You're probably better off starting with a different design.


(As an aside: this might also resolve the question in
https://forum.nginx.org/read.php?2,275668 -- when the client has no idea
what the server-secret is, there is no need to have updated clients for
a different server-secret.)


Good luck with it,

f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Sorry, only registered users may post in this forum.

Click here to login