[prev in list] [next in list] [prev in thread] [next in thread] 

List:       twig-devel
Subject:    Re: [twig-devel] "register_globals"
From:       Craig Foster <craig () wiw ! org>
Date:       2003-06-27 15:25:15
[Download RAW message or body]

It's a little more complex than that.  There are cases where a variable
in the global context could legitimately have come from get, post, or
have been set within the script, so for each place where we make a
replacement, we need to check to see how many valid places that variable
needs to come from.  Right now, TWIG just throws a lot of random stuff
into the url, so, for instance, we need to audit the code to find out
where we should expect a certain variable to come from the url, and
where we should ignore a variable from the url and assume it is an
attempted attack.  Mind you, that is an important and useful exercise,
from a security perspective, but it is not a simple find and replace,
and it is sure to cause some breakages when it happens.

The "simple" solution is to just import all the various $_GET, $_POST,
and $_COOKIE elements into the global context.  That could be done all
at once with just a few lines in index.php3.  But if you do that, you
loose the advantages of turning register_globals off.  It might not be a
bad intermediary step so that TWIG works with the default setting of
register_globals, but it is not a permanent solution (and it could get
in the way of a more permanent solution).  We should also probably go
through the code and consider if there are any potions of code that
should me moved into a function to protect them from from untrustworthy
variables in the global scope.  Even if we make TWIG work with
register_globals off, we should also make sure TWIG is secure with
register_globals on.

I'll be interested to see Aaron's function approach when we get finished
with redoing the language system.  I've been doing some work on the
session management code lately, and one facet of those changes is to
make the session management code usable with register_globals off.  That
will take care of a lot of the variables that come in from the outside,
but not the really important ones, I'm afraid.  More on that code when
it is more fully tested and ready to commit...

Tom Goulet (UID0) wrote:
> On Thu, Jun 26, 2003 at 10:17:38PM -0700, Aaron Stone wrote:
> 
>>With respect to register_globals, I have an idea for how I'd like to
>>handle it with only a modicum of code changes required... as a little
>>sneak preview of what I'm thinking, right now I'm working on making
>>translation function based. Perhaps pulling variables from the globals
>>should also be function based...
> 
> 
> I thought all that was required was to go through the code and replace
> "$foo" with "$_GET[foo]" or "$_POST[foo]" or maybe there's
> "$_COOKIE[foo]".
> 



[prev in list] [next in list] [prev in thread] [next in thread]