Results 1 to 12 of 12
  1. #1
    Join Date
    Apr 2004
    Location
    Atlanta, GA
    Posts
    550

    Blocking direct access to a file

    Hi, i'm trying to prevent a file from being access on my server. I'd like for that file to only be accessed if the user is already on the server and the referring URL is domain.com/user/section.php can this be done with an htaccess file?

    so if the user types in domain.com/user/mp3.swf the file won't load. they would have to be coming from the section.php file in order for it to load.

  2. #2
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    You can create a rewrite rule to check the referring before serving up certain file types, but a referer could easily be fooled/faked. However, if few to no users on your web site would want to bother faking it, then it's a reasonable enough method to check the referer.

    RewriteEngine on
    RewriteCond %{REQUEST_URI} path/to/file.swf$ [NC]
    RewriteCond %{HTTP_REFERER} !^https?://(www\.|secure\.)?yourdomain\.(com|net)[^\@.]/user/section.php$ [NC]
    RewriteRule .*\.(gif|jpe?g|png|swf)$ - [F,NC]

    The above is an example only. This will check that the URL is to that (or could be modified for any) sqf file first. If it is for that file, it'll check to see if it's from your site (with or without a leading www., or alternatively, a secure.youdomain.com URL -- again, just an example) at yourdomain.com or yourdomain.net. The [^\@.] just makes sure that it's not a URL that's tricking a browser, such as http://yourdomain.com@anotherdomain.com/path/to/allowed/referer or a sub domain such as http://yourdomain.com.anotherdomain.com/allowed/referer/url.here[/url].

    Then it checks for the path you want to come from /user/section.php. The ! character at the start of the condition means "not", ^ is the start of the string, and $ is the end of the string. ? means the preceding character or option or class is optional. The \. is literally . (otherwise . means any single character). [NC] means any letter case (important for the domain, though not necessarily the URL (sometimes you don't even want that for the actual URL on non Windows type systems).

    You could add an initial referer exists check says if it's not empty ! (not) ^$ (nothing between start and end of the string) is empty, for example (RewriteCond %{HTTP_REFERER} !^$), but then people with no referer (typing it direct in their web browser's location bar or from a bookmark or embedded site call on another site) could access it, so I assume you don't want that.

    The final actual rule says that if the above two (or three if the initial check is added) conditions aren't met, that it will enact the rule. That rule example will fail to serve up any file extension in the list, being *.gif, *.jpg, *.jpeg, *.png and *.swf) (to the end of the string) $, with a no letter case check [NC], if needed, and a - [F] (fail). Instead of fail, you might want to do a redirect, depending on your site's structure and the intention of it. Anyway, that's just an example for you to work off of.

  3. #3
    Join Date
    Apr 2004
    Location
    Atlanta, GA
    Posts
    550
    yeah i need a method that can't be faked. what about putting the mp3.swf behind the webroot ?

  4. #4
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    You can put it in a web root, a non web accessible directory within the web root, but in a script aliased directory (or script aliased directory path), or within a directory only accessible to your user, or even have the file set with permissions only accessible to your user (i.e., not permissions for the web server for normal file serving). Then, simply have a script require a valid login and/or session and serve it up accordingly (via the script that runs as your own user (a CGI script or phpsuxec or suphp)). There are other methods, but that would be the most common. You certainly can have the script call it from outside of the web root, provided the visitor is authenticated somehow via login/sessions, and that way if you run PHP in the Apache API (the global web server user), then you could have web server read permissions, so a normal mod_php ran script could serve it up if the user is okay to display it for.

    Another example option would be some authenticated streaming service or maybe some password protected file or directory. The point being, to ensure it's not an environmental element like a referer. You could actually build an on-the-fly session if they first hit that refering page if you don't want user's to log into any area of the site (if you just want to ensure they are coming from a valid referer) and create a symbolic link or session to serve it up based upon a unique session (maybe in combination with the IP they are accessing the site from) and have that only last so-many minutes (and cross check the session/IP against their access IP, so no one can share the link once they have a valid session from the proper access methods). Just one of many ideas of one of a hundred ways to do that.

  5. #5
    Join Date
    Apr 2004
    Location
    Atlanta, GA
    Posts
    550
    Quote Originally Posted by Tim Greer View Post
    You can put it in a web root, a non web accessible directory within the web root, but in a script aliased directory (or script aliased directory path), or within a directory only accessible to your user, or even have the file set with permissions only accessible to your user (i.e., not permissions for the web server for normal file serving). Then, simply have a script require a valid login and/or session and serve it up accordingly (via the script that runs as your own user (a CGI script or phpsuxec or suphp)). There are other methods, but that would be the most common. You certainly can have the script call it from outside of the web root, provided the visitor is authenticated somehow via login/sessions, and that way if you run PHP in the Apache API (the global web server user), then you could have web server read permissions, so a normal mod_php ran script could serve it up if the user is okay to display it for.

    Another example option would be some authenticated streaming service or maybe some password protected file or directory. The point being, to ensure it's not an environmental element like a referer. You could actually build an on-the-fly session if they first hit that refering page if you don't want user's to log into any area of the site (if you just want to ensure they are coming from a valid referer) and create a symbolic link or session to serve it up based upon a unique session (maybe in combination with the IP they are accessing the site from) and have that only last so-many minutes (and cross check the session/IP against their access IP, so no one can share the link once they have a valid session from the proper access methods). Just one of many ideas of one of a hundred ways to do that.
    do you have any examples of how to do any of these option. The file needs to be accessed by a php script but just not a direct mp3.swf access.

  6. #6
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    I could perhaps provide some examples if I knew more about it. Yes, any file you only want a script to serve up (and not direct access by just typing a URL) should be stored in some other manner, such as outside of the web root (being the best method), or permissions or in a script aliased or normal directory (though with lower permissions), but since the file stored outside of the web root is best, I'd just suggest going that route.

    As for how it's done, the script would have to do the logic to check to ensure that someone accessed it properly or in the method you desire (this really depends on several variables), so I'd need to know more. Once that authorizes the visitor to view the file, the script will serve it up.

    The manner in which you wish to serve it up might depend, but more likely the issue you primarily want to figure out, is how to determine if it should be served up. Could you give an outline with some detail about how you want it to work? I'm sure myself or others here would be glad to help with some more specific examples or ideas then.

  7. #7
    Join Date
    Apr 2004
    Location
    Atlanta, GA
    Posts
    550
    Quote Originally Posted by Tim Greer View Post
    I could perhaps provide some examples if I knew more about it. Yes, any file you only want a script to serve up (and not direct access by just typing a URL) should be stored in some other manner, such as outside of the web root (being the best method), or permissions or in a script aliased or normal directory (though with lower permissions), but since the file stored outside of the web root is best, I'd just suggest going that route.

    As for how it's done, the script would have to do the logic to check to ensure that someone accessed it properly or in the method you desire (this really depends on several variables), so I'd need to know more. Once that authorizes the visitor to view the file, the script will serve it up.

    The manner in which you wish to serve it up might depend, but more likely the issue you primarily want to figure out, is how to determine if it should be served up. Could you give an outline with some detail about how you want it to work? I'm sure myself or others here would be glad to help with some more specific examples or ideas then.
    when a user clicks the link for domain.com/user/section.php it loads domain.com/songs/mp3.swf windows a player.php file. I'm having a problem with people accessing the domain.com/songs/mp3.swf directly and bypassing the player.php page. So i'm looking for the most effiecent way to protect the mp3.swf file from being loaded if the use is not coming from domain.com/user/section.php.

    I'm assuming some method in which the directory checks to see where the user is coming from. I tried putting the mp3.swf file behind the the webroot /home/site/mp3.swf but and i put ../../mp3.swf but it didnt load

  8. #8
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    You can't call the file via the browser direct once it's outside of the web root. The script will need to still serve it up. Effectively opening the file and outputting it via the script.

    However, if you're only going to check where the user came from, then a referer check via a script or .htaccess rewrite rules will mostly serve the same purpose, where it can be faked. For now, it's better than nothing and will probably stop most users from doing direct linking to it.

    I'd still use a referer check in the script anyway, but just don't recommend relying on it only. My suggestion was to use a script to serve up the file, and when they hit the link you want them to come from, that other script creates a session file unique to them (and their IP).

    Once that session is created, then when they hit the next file, it'll open the file outside of the web root and serve it to them over the script. If the same link is accessed directly and it doesn't detect a valid session, it redirects or denies them access and doesn't serve up the file via the script (doesn't output it).

    If you use a unique session where an IP can be checked against, then someone can't create a valid session and just link to it from an offsite address (maybe faking the referer field) and have non valid users get direct access to the file.

    I apologize if that's not making a lot of sense, but for now, it would likely help a great deal if you just add the .htaccess rewrite rules (if you have the rewrite module) and then go from there. Really, I'm probably making it sound more complex than it actually is.

  9. #9
    Join Date
    Apr 2004
    Location
    Atlanta, GA
    Posts
    550
    i found this to be use fool, is it possible to put a file name into the block as well like file.swf|fileName.php to prevent direct calling the php file too

  10. #10
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    Yes, you can deny access to any file name, file extension, directory name, path, etc. via rewrite rules. You can also put in an extra check in the PHP script itself, but you do have several immediate options like that which will work.

  11. #11
    Join Date
    Feb 2005
    Location
    Australia
    Posts
    5,849
    Quote Originally Posted by acctman View Post
    when a user clicks the link for domain.com/user/section.php it loads domain.com/songs/mp3.swf windows a player.php file. I'm having a problem with people accessing the domain.com/songs/mp3.swf directly and bypassing the player.php page.
    So the users aren't authenticated, you simply want to force them to view the player.php page instead of going direct to the .swf? Is it easy to change the playlist? If so I would:

    1. put the mp3.swf file outside of the web-accessible directory, say /home/user/mp3s/mp3.swf
    2. make a symlink to it with a random filename in the songs directory:
    Code:
    ln -s /home/user/mp3s/mp3.swf /home/user/public_html/songs/dsiauetiaughajk.swf
    3. change player.php to load this file at domain.com/songs/dsiauetiaughajk.swf

    You can repeat steps 2 and 3 in a cron job every hour (or whatever interval you choose) to change the url of the file, and delete old symlinks so the old urls won't work.
    Chris

    "Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them." - Laurence J. Peter

  12. #12
    Join Date
    Jul 2003
    Location
    Olean, NY
    Posts
    143
    If your goal is to deny http access to the file:

    <Files file.swf>
    order deny,allow
    deny from all
    </Files>

    Keep in mind you'll take a performance hit because then you'll have to serve the file up with PHP, which is much slower than apache.

    The most correct way to do this is with a fastcgi authenticator, but that's a substantial programming and administration hassle.
    System administration, application development, and project management.
    http://erek.blumenthals.com/blog/

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •