Prevent direct access to php file

[felgall]

The referring domain is a user enterable field so anyone wanting to directly access the file directly will just set the referrer to the value that you expect before they make the call.

Setting a session within your page is the only way to ensure that a file is only accessible from that page since only that page has the right session set.

[sitehatchery]

Of course, the referring domain check could just be one of the several checks. It would at least keep 99% of users who don't know how to enter that variable from accessing it directly or from external links.

However, it doesn't matter anyway if one person could change this variable on their single browser. This person would have to intentionally do this. But what more would they gain since they could just access it through the site anyway? So actually being able to change the referrer variable on the browser is irrelevant in this case. They can only do it for "their" browser, which does not affect anybody else. And again, they'd gain nothing by changing this variable.

[logic_earth]

...However, it doesn't matter anyway if one person could change this variable on their single browser. This person would have to intentionally do this...

A lot of security software like Norton or Mcafee either strip away HTTP Referer or replace it. That requires zero user intervention. Using HTTP Referer is not going to work. Even proxy servers a lot of users use to hide there true identity and history mess with the HTTP Referer header.

A blank HTTP Referer header must also be accepted because if the user directly enters the address or uses a bookmark there is no HTTP Referer header sent. And again a lot of software strips it away. Second why is the user blocked because they came to your site from another like Google? That just seems insane.

[sitehatchery]

Hmm... first time I've heard about Norton and Mcaffe doing this. Sounds like something a virus would do. That's also the first I've heard that obscuring the identity changes the HTTP Referer header. Do you have any references or have you done any tests? I'm not being facetious - I'm really interested in knowing the research on this.

[sitehatchery]

When I clear my history, it doesn't affect the referrer at all.

[TheRedDevil]

Hmm... first time I've heard about Norton and Mcaffe doing this. Sounds like something a virus would do. That's also the first I've heard that obscuring the identity changes the HTTP Referer header. Do you have any references or have you done any tests? I'm not being facetious - I'm really interested in knowing the research on this.

Check Google, for more information. This is a well known fact and if you ask a professional programmer that work with webpages about the Refer header, they will say the same.

You can also read up on the HTTP header specs for more information.

[sitehatchery]

So in other words, you don't personally know - you just heard it somewhere.

[sitehatchery]

I apologize for that last remark. Yes, you can disable referrers and Norton will as well unless you change the security settings.

[sitehatchery]

Hmm... sessions. That brings me to another thought. You can disable cookies too which in this case would render the exact behavior as if you were testing for referrers and they were disabled.

[sitehatchery]

Alright, I hate to submit 4 in a row, but this is a challenge for me. The only thing I don't know what to do with is the case where they have both cookies and referrers disabled. Maybe in that case, I could compare database logs of ip addresses and times. That would get big fast, so there would have to be some sort of automatic cleanup. But here's what I came up with so far:

session_start();

function check_referrer(){
        $referring=parse_url($_SERVER['HTTP_REFERER']);
	
        //either directly typed or refererrs disabled
	if(!$referring['host']){
		//Referring host doesn't exist, so check for existing session
		if($_COOKIE['lala']==sha1('$LL...//')){
			//means they've been on this site recently even though the referrer isn't present
			return "all is well";
		} else {
			//means they haven't been on the site, or they have both refererrs and cookies disabled
			return "How do I get around this?";
		}
	} else if($referring['host']==$_SERVER['HTTP_HOST']){
	
	   return "all is well";
	
	} else{ 
		
	   return "all is not well";
	}
}

echo check_referrer();

[logic_earth]

Or you can just forget about trying to protect from direct access... As long as the browser can download the file it will be possible to get the file. Unless you actually have a big problem of users taking all your files and reposting them or whatever. I wouldn't bother worrying about a non issue until it becomes and issue.

[bakhlawa]

OK this discussion took a lively turn. The more I think about it, I find myself in the "I know anything on the net can be downloaded, but let's not make it simple for those who want to steal my content". So, with that said, here's what I'm thinking:

1. caller.php loaded with request for song1.php
2. caller.php sets session variable encrypted with known $key with value=song1.mp3 filename
3. caller.php immediately calls get.php (without any parameters)
4. get.php decrypts session variable with known $key and obtains filename song1.mp3
5. get.php DELETES session variable and streams song1.mp3

This should work in most cases:
1. Direct call to get.php will result in no file since session not set
2. Call to get.php after it is called by caller.php will result in no file since get.php deleted the session variable when called the first time
3. mp3 files are stored above webroot so figuring out their location is still not publicly accessible

This breaks if:
1. caller.php is loaded and for some reason get.php is not called. In this scenario, session variable is set, and a direct call to get.php (from browser address bar) will start streaming file. I can get around this by forcing an autostart on the flash player so that get.php is called as soon as caller.php gets loaded.

Now I just need to make this work with playlists...i.e., after song1 is played, get.php needs to play song2.mp3 but it won't since get.php deleted the session after the first song was played.

Still trying to figure it out....does the algorithm above make sense?

[sk89q]

Don't use the referrer. A lot of internet security packages block the sending of referrers the instant you install the software.

Making the player autostart won't make it much harder. In my case, I just right click a tab in Firefox and disable plugins for that tab. Then I view the page's source and download the file. In fact, I did that just a week ago on one particular site, and it was very obvious that the link failed after one request. You can say that this requires too much technical knowledge for the casual user, but viewing the source code of a page is already fairly too advanced.

However, there is one thing that you can do to make it a bit harder. You can pass a string or two to your Flash music player, and in the player, a new string will be generated that would be passed to get.php to get the file. Doing that will force the user to invoke the Flash player. (Although decompiling a Flash movie is very easy. There are also still ways to get the file while still invoking the Flash player.)

[felgall]

Hmm... first time I've heard about Norton and Mcaffe doing this. Sounds like something a virus would do. That's also the first I've heard that obscuring the identity changes the HTTP Referer header. Do you have any references or have you done any tests? I'm not being facetious - I'm really interested in knowing the research on this.

All decent security software blanks out the referrer header - it is one of the ways that the security software protects the PRIVACY of the software's owner. It is the exact opposite of something a virus would do since viruses attack the software owner while blanking out the header protects them.

That blanking out the header stuffs up the security on your web site is irrelevant because their security software is working for them and not for you and you're trying to detect where they came from is the suspect activity that the software is protecting against.

[felgall]

Hmm... sessions. That brings me to another thought. You can disable cookies too which in this case would render the exact behavior as if you were testing for referrers and they were disabled.

Sessions don't have to rely on cookies being enabled. The sessionid can be passed in other ways.

[bakhlawa]

Is this what you mean? (No cookies needed.)

caller.php

<?php
$file_only = basename($_GET['param']);
$file_only = str_replace(" ", "_", $file_only);
// These don't really matter since you're just reading from one folder and you don't check extensions or anything, but I like to do it in case
$file_only = str_replace("\0", "", $file_only); // Poison null byte
$file_only = str_replace(":", "", $file_only); // NTFS ADS
// Key
$shared_key = "something";
$timestamp = time();
$hash = hash_func_hmac($file_only, "$timestamp-$shared_key");
$url = printf("get.php?param=%s&t=%d&key=%s", urlencode($file_only), $timestamp, $hash);
?>
<embed
src="mediaplayer.swf"
width="640"
height="480"
allowscriptaccess="always"
allowfullscreen="true"
autostart="true"
flashvars="file=<?php echo htmlspecialchars(urlencode($url)) ?>&amp;showstop=true&amp;autostart=true&amp;bufferlength=3"
/>

get.php

<?php
$file_only = $_GET['param'];
$shared_key = "something";
$in_hash = $_GET['key'];
$in_timestamp = intval($_GET['t']);
$in_hash = $_GET['key'];
$expected_hash = hash_func_hmac($file_only, "$in_timestamp-$shared_key");
if ($expected_hash != $in_hash || $in_timestamp < time() - 60 * 15) { // You could do the timestamp check before computing the hash
    header("HTTP/1.1 404 Not Found");
    exit;
}
// I would still do a security check again
// And then load the file
//

After thinking this through some more, I think sk89q's solution is the best compromise. It ensures calls to get.php will work only if first called from caller.php; even if get.php is called directly it will only work for a set time limit and given anyone can get the file if they really wanted, it's the best balance between coding effort and dissuading the casual visitor.

Quick question: Even if someone views the caller.php source code and decides to use it on their own evilsite.com, the links will really just work for the time limit in the original code right? Since the source code won't show the hash being used, stealing the "view source" code on caller.php will be useless...?

Thanks again for the help.

[crmalibu]

They will see the hash, but the point is the hash will only be valid for a short period of time. Without knowing the secret salt key, they won't be able to generate thier own valid hash(very advanced user might be able to crack it given enough time and samples).

They can still screen scrape the hash though. But, they would need to fetch a new hash every so often because each hash is only valid for a finite time.

[bakhlawa]

Hmmm, doesn't this present another problem...

What about evilsite.com that has a link to "Song 1" pointing to mysite.com/caller.php?param=song1.mp3? Won't that just open up caller.php, have it do all the hash and key work to pass to get.php which will just stream the song?

Will a simple hyperlink from another site to mysite.com/caller.php break this whole "protection"?

[sk89q]

If the other person puts your website in a frame, then the song would play. Frame busting code could be used to prevent that. They cannot use a direct link to get.php, however, unless they have the hash. To get that hash, they would have to load caller.php on *their* server, because you can't just read the content of another page via JavaScript.

[bakhlawa]

What if evilsite.com has the following link pointing to mysite.com/caller.php?

<A HREF="javascript:void(0)"
onclick="window.open('http://mysite.com/caller.php?song1.mp3','evilsite player')">Listen to SONG 1 here</A>

They will be able to have links to songs on their site calling my caller.php directly and playing songs...?

[sk89q]

Yes?

I could just tell my friend verbally the URL, and s/he could just listen to it as well?

[Wardrop]

Does the original poster even know what they're trying to prevent exactly? What is the end goal of this? Is it to prevent people from stealing your bandwidth by direct linking, or what?

[kgun]

A class with private / protected properties and setter / getter methods immediately come to my mind.

Only the public methods are visible outside the class (hierarchy).

What privileges do the folder have: http://catcode.com/teachmod/

May be you have to change file permissions with a FTP program like http://www.smartftp.com/ .

Then you can use a class method to access the file from where you want.

[kgun]

And:

If you can use PHP note that the chmod function can only be used if you have the permission to do it in that folder.

[jimmy85]

A pretty interesting discussion here. Yeah I believe once you've posted it on the net, anyone determined to take something can and will do it.

Maybe the OP doesn't want anyone directly linking or others sites consuming his own bandwidth, or perhaps crawlers?

Yeah put in everything, sessions, hashes with time limit. Just to make it harder. Thought of using captchas too? So it can't be botted easily.