On Sun, 2 Mar 2003, Jamie McClelland <jmcclelland@...>
>Hi Dave --
>At first I started answering them in the code, but then realized that's
>what discussion lists are for :-).
>p.s. nice asci art section dividers.
Not done by hand I must admit. I used an app called FigWin, the original
being a Unix app called FigLet. I'm then using a modified FigLet font to
produce the section dividers. And in my editor, EditPlus, I have #
comments colour coded in a bright blue so that they stand out. All other
comments are in a dull green and not as obvious. Helps in the navigation
around the files.
>## maybe we should only check public variables here, $name,
>$PHP_AUTH_USER, $PHP_AUTH_PW , $PHP_AUTH_PW and so on, and then check
>the rest in the admin pages.
>I think you mean we should only check variables that will be used by
>pagetool.inc in pagetool.inc and check the rest of the variables in
>admin.inc - if so, yes agreed. it's best to keep pagetool.inc as small
>and fast as possible.
Yes, I was thinking of moving towards that approach.
>As for the overall register globals approach - I think it's great to
>have tightened security and you have given it a lot of thought. I
>wonder, however, about the maintainability of it - particularly with
>plugins that want to use variables (and plugin authors who will
>inevitably forget to add the hook to sanitize their variables). Also -
>there seems like a number of variables with little or no security
>implications (like $pt_version, etc.)
The security problems can occur when the value of the variable is used
in an SQL statement. If $pt_version was passed with a ; in it, with an
unsecure script that could indicate the end of the SQL statement. More
SQL could be passed in the variable after the ; and depending on how the
script echoed stuff to the screen after the SQL was used could expose
data from the database that we as developers never anticipated. I had
some URLs with information about this but I can't find them at the
moment. There was a problem with an early Pagetool release that allowed
a user to log in using a user name of admin; and no password. Not much
of the admin interface was available, but just to be able to get that
far was a security problem. I think Metabase escapes all the SQL so I
don't think we are prone to the ; SQL inject problem quite as much as we
The other major security problem area is the include()ing of files
depending on user supplied input. The only place we do that currently is
for languages, but I think we are secure there. Although that area does
need more work, mainly so we deal with dialects correctly!
>At the risk of being flamed by security jocks - what if we did this
>minor change: Keep all the extract statements at the top.
At the top of admin.inc, maybe. And after the user is authenticated.
> Then, run the register global functions on all the variables we know
>about, with particular attention to the sensitive variables. Then - if
>we forget a variable it will be still be available (because we kept the
>original extracts). If someone tries to mess with a variable that we
>have set a register global function for - it will be stopped. If
>someone tries to mess with a variable that we forgot AND this variable
>happens to been sensitive security-wise - then we'll have a security
>hole to patch. But - at least the program won't break.
OK, so maybe, just for the public variables....
we do the pt_register_globals() and then once the user is authenticated
do the extract for the rest without any further checking. Do we feel out
authentication is secure enough for that?
I do feel everything on the public side should be checked. So if after
the checks to see if we're in admin or wherever, and we not, we're still
in pagetool.inc, then we should destroy all the (possibly tainted)
variables. If we do this then plugins that need variables won't work so
the authors will _have_ to do a pt_register_globals() (via a hook) to
get the variables while developing their code. ...... I think that'll
work, and be secure.
> Also - perhaps using the debug class we could have some method of
>printing all variables not being sanitized on any given page load.
Not sure... Maybe, I'll have a think about how to do this.....
># Are we going to continue to support file based preferences? '-dg
>My vote is yes!
>1. It's easy and uncomplicated for us to support it.
>2. It gives high traffic sites the option of removing one sql call from
>every page view
>3. It gives techie oriented site admins the option of quickly editing a
>text file rather than waiting for forms to load.
>Personally, I'll use the table for all of my sites, but I think this is
>an important option to offer others.
OK, OK. I'll leave it in. It'll be interesting to see how many people
will actually use it :-)
>### all of the next bit can be deleted
>### downloads now called by name=pagetool_download so we never get here -dg
>### and I don't think we're using no_header_ anywhere now either, are
>I think so - I believe I just copied that straight out of pagetool 1...
> // Next comes the special actions - like the database tools and
>plugin installer and such...
>### is this bit still getting used? -dg
>The $pt_execute_admin_plug was originally conceived as a way for a
>plugin author to get an admin interface to show up in the admin section
>of the Pagetool interface. In other words, if I design an media upload
>plugin and I want a user to log into the admin interface and then click
>a menu item to access the media upload section, I would create a plugin
>that is executed when you click on the "media" link in the menu. Then,
>the interface for uploading media would appear in the right hand frame.
So it is all old unused stuff now then :-) Plugins should now add an
item to the treemenu, like Media currently does, via it's code.
>Ok - I think there's more, but I've got to stop for now...
OK. I look forward to the 'more' in due time. I'll have a load more to
commit soon, almost got all the User stuff as I think it should be. And
I'll update the TODO.txt to show where I think the areas to work on next
Does the Add Folder screen look OK to everyone? Do most (modern)
browsers understand the CSS so that the unordered list is displayed in a
line as coloured tabs? Just curious.........
d a v e