Secure Link Expires - URL Signing

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Secure Link Expires - URL Signing

ayman
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
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Secure Link Expires - URL Signing

Francis Daly
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        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Secure Link Expires - URL Signing

ayman
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
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Secure Link Expires - URL Signing

nginx mailing list
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 <[hidden email]> 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
<a href="http://site.media.com/mediafiles/movie.m3u8?token={generated" rel="noreferrer" target="_blank">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
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Secure Link Expires - URL Signing

Francis Daly
In reply to this post by ayman
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        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx