Prevent direct access to php 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.

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.

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”?

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.

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…?

Yes?

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

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?

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.

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.

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. :slight_smile:

Please check the cURL functions and you can see what these can do …
You can “forge” referrer , you can set any USER_AGENT you want.
You can parse the whole page and get caller to generate token for you and play the file remotely or even download.
As cURL can be set to accept sessions and cookies.
You will never know if it was user or not.
However there would be problem for cURL if caller.php is hidden in flash movie.
But crackers could decrypt the source code of flash movie and find the link, alter a bit parsed HTML site and call “caller.php” simply with an image this would trigger a session cookie.

Even YouTube can not protect their videos …

regards
feha

Late answer. cURL is an excellent language.

  1. Scroll down to the heading cURL: http://www.kjellbleivik.com/Books/
  2. Related WPW thread: http://www.webproworld.com/search-engine-optimization-forum/96864-commenting-software.html#post488186
  3. See the first post for book references.

@kgun
Hi
It is never “too late” :slight_smile:

This discussion brings to mind something my Father used to tell me…

Locks are only meant to keep honest folks out.

That said, my thoughts are this:

1.) Don’t pass the name of the song to get.php. Pass a unique reference to it, instead. This will make it a bit harder for the evil ones to understand what the link represents. You could even go so far as adding a spurious key/value pair to the URI that’s completely irrelevant and not used, such as:
path/to/get.php?song=no_cheating.mp3&ui={the song’s unique identifier}&h={your hash}&t={your timestamp}

2.) The notion of using a shared key/hash/timestamp is a good one. I think that these two methods are sufficient to prevent 99.5% of all improper usage.