0
/assets
 - file1.mp3
 - file2.mp3
 ...
 - fileX.mp3

(millions of files)

So what I want to prevent is to access the content directly if the user is not logged in like http://domain.com/assets/file1.mp3

Ideally the URL to the asset file will be changing every time a user logs in, using his session something like http://domain.com/assets/51303ca30479c7a79b75373a/file1.mp3

how to enforce it? so the goal - is to change the URLs often and before redirecting to actual binary file.

I understand I can do something like this

RewriteRule ^(.*\.mp3)$ /path/to/auth.php?i=$1

But I prefer not to use PHP to process the auth. Is there an elegant way with apache to process this issue?

thanks, Dmitry

DmitrySemenov
  • 755
  • 2
  • 14
  • 27
  • 1
    Apache has several authentication modules, which can be used to restrict access to e.g. a directory, a virtual host or a whole site. I don't believe they normally change the URL when the user logs in though; is there any particular reason to do that? – Jenny D Mar 01 '13 at 09:36

2 Answers2

1

There is no problem in using PHP (look for example https://stackoverflow.com/questions/2187200/using-php-apache-to-restrict-access-to-static-files-html-css-img-etc).

But if you do not want to use it, you can consult this answers to the relevant questions: https://stackoverflow.com/questions/6325712/deny-direct-access-of-file-except-server-localhost and https://stackoverflow.com/questions/12299556/restrict-html-files-access.

Community
  • 1
Meriadoc Brandybuck
  • 1,300
  • 9
  • 11
1

There are a number of security problems with using short-lived URLs in the way you propose.

  • The URLs and files will be cached in proxies and on the user's computers.

  • Browser toolbars (especially those supplied by companies that run crawlers such as Alexa, Google, Netcraft, Yahoo, etc.) can report URLs back to their parent companies to indicate that a bot should come and crawl that URL.

  • If you aren't using SSL, the URLs and the content of the files are easily available to anyone on the network path. This generally includes anyone on the same shared Wifi connection as the user, and since free, open Wifi is becoming more and more common, this is a likely scenario.

  • Your short-lived URLs are not short-lived enough. If a user only logs in once per day, anyone who the URL leaks to will have 24 hours to retrieve it.

  • If that long string in the URL is the user's session identifier, it's likely to leak in all the same ways as the URLs do above, but a session ID is more sensitive. Knowing the session identifier allows an attacker to hijack the session. This is how the Firesheep extension works. By trying to keep the images secret in this way you will actually expose your users to greater risk.

Using the normal method of Cookies to store session identifiers prevents the caching and browser toolbar leaking. Using SSL prevents network sniffing and some caching. Using standard HTTP auth with one of the Apache auth modules allows you to avoid using PHP.

Ladadadada
  • 25,847
  • 7
  • 57
  • 90