Restricting file downloads

Question

I'm currently creating a website for a client that will basically involve selling various files. This is obviously a really common thing to do, which is making me feel kind of foolish for not thinking of a method for doing it.

Once the purchase has been made the customer should be taken to a page containing the download link, as well as receiving emails that contain a download link and an email with information about an account that will be created for them (they will also be able to download from their account's control panel). What I'm trying to figure out is how I can hide/obscure the file's location on my server so that one person who buys it can't simply copy and paste the direct link to the file elsewhere. Even if I make the request to download a file a link of the format http://example.com/blah/download/454643, a URL which does not correspond to the actual location of the file, I think it might still be possible to locate the file on the server? I don't really understand too much about how permissions work on my server, which is why I ask. Thanks in advance :)

Answer 1

If you have access to running Lighttpd, you should definitely check out the Mod_SecDownload module. I've used this on a previous project that sold video and image files securely.

As the webserver doesn't know anything about the permissions used in the app, the resulting URL would be available to every user who knows the URL.

mod_secdownload removes this problem by introducing a way to authenticate a URL for a specified time. The application has to generate a token and a timestamp which are checked by the webserver before it allows the file to be downloaded by the webserver.

The generated URL has to have the format:

<uri-prefix>/<token>/<timestamp-in-hex>/<rel-path> which looks like "yourserver.com/bf32df9cdb54894b22e09d0ed87326fc/435cc8cc/secure.tar.gz"

<token> is an MD5 of

1. a secret string (user supplied)
2. (starts with /)
3. <timestamp-in-hex>

As you can see, the token is not bound to the user at all. The only limiting factor is the timestamp which is used to invalidate the URL after a given timeout (secdownload.timeout).

Answer 2

A lot of download urls I've seen that are based on purchase tend to use some guid and other dynamic information as part of the url to not make it as simple as guessing one id. You could end up with guid/datetimepurchased/id or something like that as part of the path.

An additional option would be to ensure the user is logged in before allowing the download to proceed which would given an additional layer of security.

Answer 3

Some webservers, such as Lighty and Nginx, implement the X-Sendfile header. Let's say you have a Django app, you can have your view return an X-Sendfile header which points to the file you want to ship out. lighttpd will then serve that file instead.

The file can be in a non web-accessible location (this is not a 301 redirect) and because your app is serving the header, you can do authorisation first.

This is much better than serving static files from your application. The webserver is optimised for static files and will be faster, and much lighter on resources. If you're handling more than a few requests you should consider using X-Sendfile.

There's quite a good blog post about it here:

http://blog.zacharyvoase.com/2009/09/08/sendfile/

Lighttpd/PHP instructions can be found here:

http://redmine.lighttpd.net/wiki/1/X-LIGHTTPD-send-file

NGINX instructions can be found here:

http://wiki.nginx.org/XSendfile

There also appears to be an early release Apache mod that does the same thing:

https://tn123.org/mod_xsendfile/

Answer 4

Store the files out side your web root, but then be sure that the folder you store them in is in the "open_basedir" directive in your php.ini file, this will allow you to access them from a PHP script. Storing them outside the web root means that they wont ever be directly accessed via HTTP.

Have a PHP script, like the ones listed in these answers that can stream/read out a file. If its a large file you may need to change the "max_execution_time" to account for the extra time the script will take to read out the file. This script will allow you to authenticate the user and check that they have paid for the file.

Put a .htacces in the folder with the script that rewrites the file requested from that folder to a variable. That makes it appear as though they are directly accessing the file while that are not. Personally i would only put the single script in this folder just to keep things simple. So:

http://www.yourdomain.com/files/expensive_song.mp3

actually rewrites to:

http://www.yourdomain.com/files/download_file.php?filename=expensive_song.mp3

Good luck.

Answer 5

Well, first, you definitely don't want to link directly to the file. You'll probably want to send the user a link to a service you've created (or even just a page) with a generated id argument that results in a file download, if certain criteria are met.

Those criteria are difficult, really, as you need to allow the user to download the file more than once (in case he fails to download the complete file the first time, or deletes it accidentally, etc.), but once a link works, it works until you kill it.

I'd suggest either using time or IP to filter your download requests.

Time: When someone purchases the file from you, inform them that they'll be able to download the file for 1 day only, or some such. Yes, other people can download the file during that day, but only for 1 day. You could also put a download limit on this, so they can only download it 5 times (this is normal).

IP: When someone purchases the file from you, inform them that they'll only be able to download the file from that IP. Your download service can certainly check this when they attempt to download the file.

It seems both are easily usable at the same time, as well.

In either case (or both), be prepared to handle customers who didn't download the file in time, or want to get it again after the time limit (or from another computer/IP (some people don't get static ones)). They won't want to pay again, and probably shouldn't have to.

Answer 6

You basically don't give the users the direct URL to the file. Server based permissions have nothing to do here.

Say you have the required file(s) saved in /data/files/file.pdf (good practice to store files out of your web root). You can provide the users a link to download which looks something like /download.php?auth=32

When a user clicks the link, download.php will check if the session/cookie is authenticated and if the download id is valid (in case you have time based download expiry) Then download.php will read the required file from its location and send it to the browser with appropriate headers to force download.