[CLUE-Tech] Cracking websites

[Jed S. Baer]

On Sun, 22 Feb 2004 01:01:45 -0500
Angelo Bertolli <angelo at freeshell.org> wrote:

> But what's the crack?  You can still only do things as apache or 
> nobody.  Of course if you're afraid of people seeing certain files, make
> them unreadable by apache.  Linux systems aren't locked down that 
> tightly by default.  By default people with shell accounts can read 
> lilo.conf, which keeps the password unencrypted.  To fix this problem, 
> you make certain files go-rw I guess.  The shadow file is locked down 
> though.
> 
> Also, you can also tell apache to run "as if another user."  I know with
> virtual hosting you can give it a different user for each site.    I 
> think using  <Directory> </Directory> in httpd.conf you can do this too 
> for certain directories.

I specified a shared hosting environment. In a virtual server environment,
yeah, the problem shouldn't exist.

Making a file unreadable by the httpd daemon makes it unusable for your
website. I'm talking about files which are needed by your website. Those
files must be readable by whatever user the httpd daemon is running under.

For example:

Imagine the httpd daemon runs as nobody, and nobody is a member of only
one group, also called nobody. I am jbaer:users.

I have these files:

  /home/jbaer/public_html/foo.php
  /home/jbaer/config/config.php

If I invoke foo.php from a web browser, it runs on the web server as user
nobody. If foo.php needs to read the above config file, then that file, if
it is owned by me, must have world read privilege. Or, it can be owned by
nobody, with a privilege mask of rw-------, but either way, it must be
readable by the httpd user -- no matter what that user is. In a shared
hosting environment, that user is always the same user.

Therefore, files in other peoples directories must also follow the same
constraints.

Since my cracking script runs as the httpd daemon user, anything the httpd
daemon can read, my script can read.

It appears that PHP has some ways of addressing this, and I imagine Perl
does too. But since it's possible to write CGI programs using shell
scripting, C, or any language the host provides, the restriction should
really be handled in the web server itself.

jed
-- 
http://s88369986.onlinehome.us/freedomsight/

... it is poor civic hygiene to install technologies that could someday
facilitate a police state. -- Bruce Schneier