restricting file access thorugh web browser...

[polkwaves]

You are absolutely right and security issues were always at the back of my mind. Thank you for alerting me to this vulnerability.

I did a test run to determine if indeed the vulnerability is possible. I typed the following into the browser and was able to download the zip file with contents intact.

http://example.com/test.php?name=blah.zip

You mentioned that I should make the script secure. Isn't the memberstatus check sufficient for that purpose or can script kiddies circumvent that check?

As far as dealing with current members, I will check to see if the get variable passed to the script ends in ".mp3" and check for other suspicious characters before serving the mp3 files.

Thanks again.

[voodoomagic]

you need to restrict permissions on the directory, and keep all protected files in there, and have a script that allows the user to download the file require logged in status to be confirmed.

then in the script read the file and output it to the browser. to see what types of headers you need, use: http://www.web-sniffer.net to view the response header that is sent by the browser, and send the same ones with your script. then send the file contents, and it the browser will download the file.

this way a users browser cannot view the files, without being logged in and downloading them via the script which requires user authentication.

-voodoo

[polkwaves]

you need to restrict permissions on the directory, and keep all protected files in there, and have a script that allows the user to download the file require logged in status to be confirmed.

then in the script read the file and output it to the browser. to see what types of headers you need, use: http://www.web-sniffer.net to view the response header that is sent by the browser, and send the same ones with your script. then send the file contents, and it the browser will download the file.

this way a users browser cannot view the files, without being logged in and downloading them via the script which requires user authentication.

-voodoo

That's great advice and I will certainly perform those tasks. thanks

[Tarh]

You mentioned that I should make the script secure. Isn't the memberstatus check sufficient for that purpose or can script kiddies circumvent that check?

As long as the script that creates that session variable is secure, you should be fine. However, there may be some issues with session security, so make sure that you fix any of those (see "Sessions and security" in the PHP manual here, and read up on session fixation to see what you're up against), but that's a different issue entirely.

As far as dealing with current members, I will check to see if the get variable passed to the script ends in ".mp3" and check for other suspicious characters before serving the mp3 files.

Make sure you remove all slashes and dots from the filename (with the exception of the extension). A better solution would be to remove the ".mp3" part from the URL entirely and append it in the script, but from the previous posts it appears that such a method is problematic for the rest of your system.

The best solution in your situation would be to have a list of files stored somewhere on the server (database, HTTP denied .txt file, etc.) which can be accessed by your script. When the script starts, it reads the file to see if the $_GET parameter is a legal one, otherwise it dies. The best way to think about securing your scripts is: instead of dropping invalid input, only accept valid input.

[voodoomagic]

as far as implementing Tarh's idea of using a list in combination of my idea, its basically to ensure that someone doesnt try and spoof a request for a file that shouldnt be given to the user such as passwords, or just other things etc.

implement my idea, and for the script that actually sends the file, have it check against that list whether its inxml or in a database or whatever. but yea definitely a list. never trust any kindof information that comes from your user no matter who they are, even if they are logged in members. always check the input to ensure its valid. so using a list would definitely add a level of security to your site.

[polkwaves]

As long as the script that creates that session variable is secure, you should be fine. However, there may be some issues with session security, so make sure that you fix any of those (see "Sessions and security" in the PHP manual here, and read up on session fixation to see what you're up against), but that's a different issue entirely.

Thank you for the wealth of information.

Make sure you remove all slashes and dots from the filename (with the exception of the extension). A better solution would be to remove the ".mp3" part from the URL entirely and append it in the script, but from the previous posts it appears that such a method is problematic for the rest of your system.

I don't think this should be a problem. I will look into it.

The best solution in your situation would be to have a list of files stored somewhere on the server (database, HTTP denied .txt file, etc.) which can be accessed by your script. When the script starts, it reads the file to see if the $_GET parameter is a legal one, otherwise it dies. The best way to think about securing your scripts is: instead of dropping invalid input, only accept valid input.

but yea definitely a list.

To what are you guys referring to as list? Are you guys suggesting that I pass a reference to the mp3 files such as "test.php?id=1" and then look up the database for the filename corresponding to the id number?

thank you both for your valuable time and advice.

[Tarh]

To what are you guys referring to as list? Are you guys suggesting that I pass a reference to the mp3 files such as "test.php?id=1" and then look up the database for the filename corresponding to the id number?

That's the best idea.

If -- for whatever reason -- this is not possible and you need to send a parameter with a .mp3 extension, you could have a text file with something like:

file1.mp3
file2.mp3
file3.mp3

Then the script would load each line into an array, and not accept any parameters if it did not appear in the array.

But, if you're able to, definately go for the linked filenames in a database.

Also, if you don't want users to be able to guess the next file in the sequence (using incrementing numbers is pretty obvious), you could always use hashes of the files for file IDs.

[polkwaves]

ahh. I gotcha.

I will implement the database option.

Once again, thank you for your time and valuable input. I will report back if I should experience any problems in the near future. Thanks again.

[polkwaves]

Also, if you don't want users to be able to guess the next file in the sequence (using incrementing numbers is pretty obvious), you could always use hashes of the files for file IDs.

Do you mean that I should dynamically generate the encrypted hashes during "playlist.m3u" creation and then decrypt those values in the test.php script?

what is the best algorithm for such a purpose?

Thanks

[Tarh]

Do you mean that I should dynamically generate the encrypted hashes during "playlist.m3u" creation and then decrypt the those values in the test.php script?

You seem to be confused about the different types of encryption. Cryptographic hashes are basically extreme compressions of input data; so much so that it cannot be reversed. Therefore, you cannot "decrypt" a hash, which is the purpose of creating a hash. For a very in-depth audio discussion of cryptographic hashes, check out Episode 35 of Security Now (the episode is 34 minutes long; consider listening to the audio while reading along in the transcripts).

Basically, when adding a new mp3 to the m3u file, read in the entire mp3, compress it down to a hash, and then create the m3u as normal. Then, take that generated hash and put it into the database mapped to the actual filename. That way, if you added three mp3s to your playlist, the URLs might look like:

test.php?name=435b5c6775b4d1c4e9f84624fa861e33
test.php?name=448924aa68c76499925238b6afe4a522
test.php?name=2c19714caf7583f5d3dede550fac894e

...slightly harder to guess the next item in the sequence.

As for hashing algorithms, if you have PHP 5.1.2, check out the page on hash functions. Otherwise, since this is not a mission-critical operation, you could get away with using a simple MD5 function call.

[polkwaves]

Thanks
I will certainly listen to the audio transcripts and look further into the MD5 function call.

Wouldn't it be more efficient to just generate random numbers, 16 digits in length perhaps, and then associate that number with the actual mp3 file name in the database? Something similar to this:

$a=rand(1000,5000);
$b=rand(1000,5000);
$c=rand(1000,5000);
$d=rand(1000,5000);

$randnum=$a.$b.$c.$d; 

I'll try this out and report back if I should run into any problems. thanks again.

[polkwaves]

seems like that would not be a good approach since someone could sit there and run a loop that generates 16 digit random numbers and sooner or later they may match numbers in the database. So, hashing, which produces a unique string should do the trick, unless there are work arounds to this as well. I doubt this but I'll try. Thanks

[malluwood]

http://www.zend.com/zend/trick/tricks-august-2001.php

This may solve

[Tarh]

Wouldn't it be more efficient to just generate random numbers, 16 digits in length perhaps, and then associate that number with the actual mp3 file name in the database?

That would be more efficient, but it doesn't matter very much since both methods are extremely fast. Also, hashing has some unusual benefits.

Consider this:
You add a file to the database and a hash is associated with it. A user visits your mp3 page and bookmarks it in their browser. Through an unrelated security hole, a hacker deletes your database. You manage to patch the hole, but have no database backups. When you add the file to the database again, hashing it will produce the exact same results, allowing you to restore the database. The random user at the beginning of the example can continue to use their bookmark, because the page has been restored with the same name.

http://www.zend.com/zend/trick/tricks-august-2001.php

This is a very old script (2001) which uses outdated and dangerous technology. If you were to use parts of this script, use the PCRE functions instead of ereg(). Additionally, it would be wise to modify the regex to only allow for one period, followed by a known extension. Again, though, this script is looking at the security aspect in the wrong way -- it's trying to disallow invalid input. Also, never use any scripts which rely on register_globals, such as this one. If you see a script which requires register_globals, you might as well ignore the rest of the code and look elsewhere, because the author clearly doesn't write code for web developers who care about security.

[polkwaves]

Thank you for the information. I will opt for the hashing method and do further research on php/web security. Thanks again for your time and invaluable advice and my thanks goes out to all who have taken their time to respond to this thread.