Protecting individual files/dirs from access
Skip Evans
I hope this isn't too off-topic for this list, but
I have a need to protect dynamically created
directories in an Apache environment and not sure
the best way to go about it.
It's yer basic LAMP environment, and what will
happen is that the client will be uploading a
musician's sound files to his/her own directory
and then allowing them to be downloaded by people
who pay for them.
So the directory for the artist, which will be one
level below the docroot, like
public_html/greatsinger/, will contain the
artist's music, and must be accessible by those
who have paid for the music, but should be
protected from any typed URL attempt to access the
music files directly.
I was wondering if it were possible to drop a
.htaccess file into each artist's directory that
would password protect it and then code the URLs
in the PHP script that allows access to the fines
to access the files with a user name and password,
but also hid this URL from display in the browser?
The files need to be under the document root to
allow a link to download them, right?
Any suggestions for common ways to solve this
would be appreciated.
--
Skip Evans
Big Sky Penguin, LLC
61 W Broadway
Butte, Montana 59701
406-782-2240
http://bigskypenguin.com
=-=-=-=-=-=-=-=-=-=
Check out PHPenguin, a lightweight and
versatile PHP/MySQL development framework.
http://phpenguin.bigskypenguin.com/
AlmostBob
of what you want and has a good explanatory on how to get your dl files out
of the document path included in its instructions
--
If at first you dont succeed
try try try again
If at first you do succeed
try not to look surprised
_
"Skip Evans" <sk...@bigskypenguin.com> wrote in message
news:461FB344...@bigskypenguin.com...
Richard Lynch
> So the directory for the artist, which will be one
> level below the docroot, like
Don't do that.
You have to work WAY too hard to make sure you have a gate-keeper to
force people to pay.
Put the files outside the webtree, and have a PHP script that controls
access and is your gate-keeper.
It's kind of like the difference between holding a music festival in a
park with no fence, and holding a music festival in a convention
center.
In the first case (your mp3 in the web-tree == open park) you end up
having to build a fence, and there will always be somebody trying to
jump the fence, because it's just a temporary fence and obviously not
very secure.
In the second case (the mp3 outside the web-tree) there's a big brick
wall and a tiny number of doors that need guarding, and it's much
easier to secure.
> I was wondering if it were possible to drop a
> .htaccess file into each artist's directory that
> would password protect it and then code the URLs
> in the PHP script that allows access to the fines
> to access the files with a user name and password,
> but also hid this URL from display in the browser?
You could do all that, but...
> The files need to be under the document root to
> allow a link to download them, right?
No.
Have the link go to a PHP script, which authenticates the user (in
your case, makes *sure* they paid) and then that script does
http://php.net/readfile
The MP3 itself should live outside the web-tree in a "private" directory.
You'd still want to have the sub-directories under "private" organized
by artist and all that.
Your upload script would simply move files into this directory tree
instead of the web tree -- which is better anyway, as that means you
needn't have php-writable directories inside your web-tree, which is
also a Risk.
You *DO* have to have your download URL cleverly-crafted to make the
browser do the right thing, and you have to send the right headers for
the MP3 right before the readfile, but that's actually quite easy with
$_SERVER['PATHINFO'] and header() function.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
tedd
>Put the files outside the webtree, and have a PHP script that controls
>access and is your gate-keeper.
Richard:
How secure is this:
There are seven files there, namely:
http://sperling.com/a/pw/.htaccess
http://sperling.com/a/pw/a.php
http://sperling.com/a/pw/b.php
http://sperling.com/a/pw/auth.php
http://sperling.com/a/pw/index.php
http://sperling.com/a/pw/girl.gif <-- not protected.
http://sperling.com/a/pw/girl.jpg <-- protected, but well worth the effort.
Are any of these files accessible, even when you know the path? And
by "accessible" I mean can you obtain any information that the files
contain?
For example, if I were to tell people to store their user id and
password in a configuration php file with a known path, would it be
safe? I realize that if the server is breached then nothing is safe,
but barring that -- how safe would that be?
Thanks,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
Richard Lynch
> At 4:56 PM -0500 4/13/07, Richard Lynch wrote:
>>Put the files outside the webtree, and have a PHP script that
>> controls
>>access and is your gate-keeper.
>
> Richard:
>
> How secure is this:
I can't answer that question definitely just looking from the outside
in...
A deadbolt may look secure from the outside, but if it's balsa-wood
behind the locked door, that deadbolt ain't worth squat. :-)
> http://sperling.com/a/pw
>
> There are seven files there, namely:
>
> http://sperling.com/a/pw/.htaccess
> http://sperling.com/a/pw/a.php
> http://sperling.com/a/pw/b.php
> http://sperling.com/a/pw/auth.php
> http://sperling.com/a/pw/index.php
> http://sperling.com/a/pw/girl.gif <-- not protected.
> http://sperling.com/a/pw/girl.jpg <-- protected, but well worth the
> effort.
>
> Are any of these files accessible, even when you know the path? And
> by "accessible" I mean can you obtain any information that the files
> contain?
index.php is also accessible, if I can guess the login, which I did on
my first try...
a.php is also then accessible.
I can then visit b.php and auth.php, which do not seem to generate
output.
girl.jpg remains in accessible, however, afaict.
> For example, if I were to tell people to store their user id and
> password in a configuration php file with a known path, would it be
> safe? I realize that if the server is breached then nothing is safe,
> but barring that -- how safe would that be?
Consider the following scenarios:
SCENARIO #1
Your webhost is about to go out of business, and you tar up your site
in a super big hurry, and slam it into a new server.
Whew!
You check it out, and it works, and you toddle off to bed exhausted.
Turns out, though, that the .htaccess files didn't get into your
tarball, because you forgot that you needed to add them explicitly.
So a bunch of stuff in your webtree on your shiny new server is wide
open.
Yes, this has really happened.
To me.
Fortunately, I had other stuff in .htaccess that made it obvious that
something was wrong, and the window of opportunity was short, but
there it is. And it wasn't like the world was gonna end or anybody's
money was at risk or even anything personal info, really. But
still...
SCENARIO #2
The server admin (possibly you, possibly not) upgrades Apache, and
somehow manages to not install PHP.
Or, perhaps, doesn't use the same extensions (.php3 anybody?) for PHP.
Or, perhaps, messes up that line and forgets to add the .html you've
grown accustomed to being passed through PHP.
Any one of these can suddenly expose your password to the whole Internet.
These are things that should not happen, but have happened, and will
happen again, to somebody somewhere.
If you put the stuff you want to keep private OUTSIDE the web-tree,
and provide a PHP gate-keeper to get to it, you reduce your risk.
It's a lot harder to screw up bad enough to configure Apache to start
serving up files directly from a "private" directory.
I won't say nobody has ever managed to do that.
In fact, I'm sure somebody somewhere has managed it with a
+FollowSymLinks and then putting a symlink in the web tree out to the
private dir, because they didn't know how to work PHP's
include_path...
But it takes a lot more work to mess that up than a simple common typo.
So it's not about whether I can get to the stuff NOW.
It's about whether things could EASILY go wrong enough that I could
get to the stuff tomorrow.
Let's also consider the case of my visiting b.php and auth.php
In this small tiny sample application, it's unlikely that either of
those do anything "interesting" enough when I visit them out of
sequence.
However, in a LARGE application, if the user visits a .php file
completely out of sequence from any QA process you have ever run,
because they are surfing to random .php files to try and "break" your
application, what happens?
A: PHP code is executed completely out of context, in a manner you
have never ever tested at all, much less subjected to any kind of
formal QA process. In essence, the visitor is running code that
you've never even tried, at least not in that particular environment.
As code grows and accretes more and more cruft, and a large complex
web application emerges, can you really guarantee that the user
running some arbitrary chunk of PHP code out of sequence like that is
never ever going to be a problem? Use PHP's include_path and get the
include files OUT of your webtree.
PS I'm assuming that you intended it to be easy to guess the login for
the HTTP Basic Authentication... :-)
PPS Nice photo! :-)
tedd
>index.php is also accessible, if I can guess the login, which I did on
>my first try...
Well, I did provide the log on and password on a subsequent post.
BUT, I didn't try to make it hard to guess, that wasn't the point of
the post. I was trying to see what files were considered "secure" and
what files weren't.
---
>I can then visit b.php and auth.php, which do not seem to generate
>output.
As you said "PHP code is executed completely out of context, in a manner you
have never ever tested at all...."
So, I try to make my include scripts produce nothing when called
independently. I've seen techniques where a token must be correct
before running, but I just make my includes dependant upon variables
in the calling script.
---
>If you put the stuff you want to keep private OUTSIDE the web-tree,
>and provide a PHP gate-keeper to get to it, you reduce your risk.
I'm sorry, I should know this, but I don't.
You see, I work totally in hosted environments. They provide me with
several folders from "anon.ftp" to "web_users" (including a "private"
folder).
I start building from inside httpdocs folder where I place an
index.php file and then branch out from there. Now, where is "OUTSIDE
the web-tree"?
>It's a lot harder to screw up bad enough to configure Apache to start
>serving up files directly from a "private" directory.
I have a "private" directory, but if I place files in it, I can't
read them via php -- I get a:
Warning: fopen(): open_basedir restriction in effect.
I've read how one can turn that off, but I have not been successful
in doing so.
---
>PPS Nice photo! :-)
http://sperling.com/a/pw/girl.jpg
Now you got me going, how did you get that? Even my php scripts can't read it.
Or are you putting me on? Send me a copy of it back-channel. :-)
Cheers,
Richard Lynch
> I start building from inside httpdocs folder where I place an
> index.php file and then branch out from there. Now, where is "OUTSIDE
> the web-tree"?
Not inside httpdocs folder is OUTSIDE.
If you put a file there, nobody can surf to it.
But PHP can still 'include' it with a good setup of include_path in
.htaccess or even with http://php.net/set_include_path at the top of
each script if .htaccess is turned off.
>>It's a lot harder to screw up bad enough to configure Apache to start
>>serving up files directly from a "private" directory.
>
> I have a "private" directory, but if I place files in it, I can't
> read them via php -- I get a:
>
> Warning: fopen(): open_basedir restriction in effect.
Get your webhost to give you a directory that's not in httpdocs, but
*IS* in open_basedir restricted list -- Nobody but your webhost can
fix this.
> http://sperling.com/a/pw/girl.jpg
This one I cannot read.
> Now you got me going, how did you get that? Even my php scripts can't
> read it.
--