[Phpwiki-talk] Security (was: Re: new admin/ directory)

[Steve W. <sw...@wc...>]

On Wed, 5 Jul 2000, Jeff Dairiki wrote:

> Why is this in it's own subdirectory?  Why not just an admin.php3 in the
> main directory?

I wanted to keep files grouped according to their function, more or less.
Putting everything in admin/ solved this, from my point of view...

> I think all the files which get included or required should be moved into
> a 'lib' subdirectory.  This is mostly a security issue as it makes it much
> easier to prevent people from directly browsing eg. 
> http://blah/wiki_display.php3.
> (Not that this necessarily does anything bad, but there's no reason for
> that to be a valid URL at all.)

It would only be as secure for as many people out there who don't know
there is a lib/ and I'm sure lots of script kiddies read Freshmeat on a
daily basis... 

> I suggest that only index.php3 and admin.php3 should be in the top level
> directory. These will 'include "lib/wiki_config.php3"' (or maybe 'include 
> "wikilib/config.php3"'?)

That might be a cleaner solution; but I wanted to start coding admin stuff
now, and not clutter the main directory. I dunno. What do you think, Arno?
admin/ or lib/?
 
> (PHP, as you probably know, does support an include search path via the
> configuration variable php_include_path.  When PHP is run as an Apache
> module, this path can be set in the local .htaccess file.  With other
> servers, this is probably not so easy.   One could write ones version of 
> include
> using file_exists().)

I'm very flexible on the directory issue but I won't back down on ease of
installation. A lot of people who've installed PhpWiki don't have access
to the server itself. (Myself included; on Sourceforge!) Any changes that
mean something won't work "out of the box" is going to meet stiff
opposition from me :-) 

(Try installing a few other Wiki clones and see how long it takes to get a
Wiki up and running to the point where PhpWiki is...)

> When apache is configured to do external authorization, the variables
> $PHP_AUTH_USER and $PHP_AUTH_PW never get set.  The solution, in this
> case, is just to delete the authorization stuff from admin/index.php3,
> since the httpd is handling this anyway.
> 
> This is confusing though (for admins setting up a phpwiki, that is).
> To maintain maximum plug-and-playness, it might be better to implement
> authentification entirely within php.  The drawback to this is, as always,
> added complication: it probably requires cookies and some sort of session 
> management.

I wasn't aware of this, thanks for bringing it up... I intended to put in
a comment in the code inviting a better solution to authentication. 
Perhaps we will just have to document the problem if the user wants to run
PhpWiki on an Apache server that does auth. (Is that, btw, the same as the
.htaccess file? I haven't set up one of those since 1997.) 
 
> Files and directories which are writeable by through httpd make me nervous,
> and I try to minimize their number.  (Of course the main databases need to
> be writeable, so maybe my fear in moot.)

Agreed. Ideally PhpWiki is run by someone who has a clue; I suppose that's
wishful thinking on my part :-) At this stage we've been really lucky
because people interested in Wikis in general are pretty intelligent
people (present company included :-) so it's been pretty smooth.

Whenever I've added something that means "the server can write to it," be
it a DBM file or a directory, I think very carefully about it. Being able
to dump Wiki pages to a directory doesn't sound too dangerous, since the
input has to be a dbm file (or it fails completely).  Where it's being
written has to be writable by the server, so if some bad guy in a black
hat decides to hack a PhpWiki and dump all the pages to /tmp he can do
so... if the server runs as root (bad!) he could name a page "passwd" and
dump the pages to /etc. So a careful check of the directory the user
provides will be crucial. We can start by limiting it to anything under
/tmp and anything under the server root; nothing with ".." will be
allowed; and if the out-of-the-box constraints are too stiff they have
GPL'd source code that they are free to do with as they please! 

That said, I'm sure another security vulnerability lurks somewhere. It
might be better to ship PhpWiki with admin functions disabled, and the
user has to enable it. (It has no login/password now and won't work until
they edit the script.)

Also, a friend recently asked me what's to stop him from uploading a
uuencoded warez file and I said nothing; but maybe we want to set a hard
limit on page sizes anyway, like 1M or maybe 500,000K. That could be a
define() in the config file and a check on the size of the page in
wiki_savepage.php3. 
 
> Another slick alternative might be a PHP script which creates a tar- (or zip-)
> file dump of the wiki on the fly (to be saved on the web-clients, rather than 
> the
> web-servers disk.) 

THAT is a very interesting idea...


> >The Perl script shrank the DBM file on wcsb.org from 2,464,640 bytes to 
> >117,574 (there are 91 pages in it).
> 
> Maybe wiki_dbmlib can do this automatically every once in awhile?

It would have to be an admin function because if you decide that the first
user after 4am every day triggers the rebuild, you are counting on that
user to not stop the transaction before it's done. (i.e., click the "stop"
button and interrupt the rebuild.) That makes me nervous.

sw


...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain