Archive of UserLand's first discussion group, started October 5, 1998.

Secure Prevention of Deep Linking

Author:Jim Flanagan
Posted:8/10/1999; 2:22:30 PM
Topic:Deep Linking
Msg #:9320 (In response to 9309)
Prev/Next:9319 / 9321

Jeremy Bowers writes:

There are many technical possibilities. The one I came up with involves creating a permission token of some kind, and embedding it (dynamically) into the querystring on the link, recording that that is legal to follow for, say, 10 minutes, after which, you need to reload the page for a new one. (No cookies, no broken links, all you need is a database, and a competent programmer could put this together in hours. For real security, add IP tracking, so even a script to pull a current link off a page won't work.)

I came up with a few in my head as well, and the one which Jeremy suggests is the most sensible. Here's a way to make it very secure, and not require a database (or any state):

The webserver has a token, which is kept secret, and changed every day. When the user hits the "gateway" URL, a page is generated where links into content are via a CGI with URLs that include a reference to content, a timestamp and a token which is of the form

MD5(clientip + timestamp + secret)

Where '+' can mean either concatenation, XOR or any suitable combination operator. Replace MD5 with your favorite hash. The tokens guarantee access for that IP address for a preconfigured amout of time (1 hour), and cannot be forged (it is unlikely you would be able to extract the secret token from the hash). A faked or expired token simply re-loads the gateway page (or generates a nastygram, if that's your thing...)

The URL then looks like:

http://www.stingy.com/stories/deeplink?ts=934319263&tk=7fab539d59ff83c2e91a049acb123a4b

The server doesn't need to check a database of links to verify that the code is correct, nor does it need to maintain any state on a per-client basis.

The content CGI only needs to re-compute the hash based on the client's IP address, the supplied timestamp (ts=) and it's own secret token, and compare it with the supplied client token (tk=). If they're the same, then the URL is valid and the content is supplied.

There are responses to this message:

This page was archived on 6/13/2001; 4:51:48 PM.

© Copyright 1998-2001 UserLand Software, Inc.