Securing my audio - is this good approach?

[bhuether]

Based on some posts I made here and the responses, I implemented an mp3 protection scheme on my site. My site has guitar lessons and people need to be logged in to listen to audio. So here is what I have:

- Folder Structure: /home/audiofolder(outside webroot)
I have this set to 777 permissions because it seemed to be necessary for everything to work... What is really needed? It is also htaccess protected (not sure if that even makes sense for folder outside webroot)

- Scripts: When people click an audio link, that brings them to a function that checks if they are logged in. If not, they get a message. If they are logged in the script displays a flash player object (XSPF player). The flash player is given an mp3 url of form

mysite.com/somefolder/getaudio.php?id=X

getaudio.php first checks if they were referred from domain www.mysite.com. Code is

$ref = $_SERVER['HTTP_REFERER']; 
$domain = 'http://www.mysite.com/'; // your domain 
if(substr($ref,0,strlen($domain))!= $domain ¦¦ !isset($ref) ¦¦ $ref == ''){ 
// flash object code goes here
}

If not, they hear audio clip telling them to not try and steal my audio. Otherwise, the script outputs the audio to the flash player. That code is

$filename="/home/audiofolder/somefile.mp3; // this is done based on the id var that is passed...
header("Content-type: application/audio-mp3"); 
header("Content-length: ".filesize($filename)); 
$fh=fopen($filename,'r'); 
while ($data=fread($fh,1024)) { print $data; flush(); }

So far it seems to work. But I am no expert at this stuff and have no idea if there are holes. I am not looking for perfection - just want a pretty damn good protection scheme.

thanks,

brian

[PHP_Chimp]

Your security comes down to checking that the refering page is on the same domain. The problem with a lot of the $_SERVER array is that the information comes from the client. Things like the UA string, IP address, etc are all set by the client.

If you want to see what is set by the client then have a look at the actual http request. For this page my request looks like -
Host www.webmasterworld.com
User-Agent Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0.12
Accept text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language en-gb,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 300
Connection keep-alive
Referer http://www.webmasterworld.com/postv4.cgi?action=reply&forum=88&discussion=3610607
Cookie Webmaster.some_information_that_I_have_faked

All of that information can be faked, and your referer is in there. As with everything set by the client you cant trust it. As you have no control over what the client does at there end.

As with everything security related it all comes down to how much effort you are prepared to put in to stop people and the inconvenience you are going to put your users through. You could require a secure connection and password access, but this may well stop people using your site. So what you have is 'security' * rather than security.

I just re-read your post and noticed that you already have logged in users. So that helps to protect your audio, assuming that you have checked that the audio cant just be accessed with no password.

I am not looking for perfection - just want a pretty damn good protection scheme.

So that depends on your definition of "pretty damn good". Ask yourself who are you trying to stop? Is it the guy that wants some cool music for there personal site, but dont want to download it and serve it themselves? If so what you have is probably enough, as they are unlikely to cURL for your track (there is an example in the cURL manual of faking googlebot, if you want to see how it is done).

You need to decide how much additional hassle your users will accept and plan security with that in mind.

*
The quoted version is the illusion of security [dictionary.reference.com] (as it doesnt fulfill the first criteria on the definition I chose), not the actual thing. As what you have is easily bypassed, assuming you have access to something like cURL...but this requires more infrastructure than some little muppet is likely to posses. However most people on this forum could easily bypass that protection.

There are no applications on the web that are truly secure. As there is always some risk with allowing people access to information. So the level of 'security' is all relevant to the content you are protecting.

[edited by: PHP_Chimp at 11:28 am (utc) on Mar. 26, 2008]