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