James, in a word -- AWESOME.
Thank you so much!! Marian --- In [email protected], James Keeline <[EMAIL PROTECTED]> wrote: > --- Marian Briones <[EMAIL PROTECTED]> wrote: > > I have been advised to quit using global variables and don't know how > > to write scripts without using them. I'm rather baffled. Can someone > > help me to see the light? I know it is a security problem; my server > > is already a target, and I need to tighten it up. > > > > Thanks in advance. > > > > Marian > > > I can think of two things in PHP which could be considered to be "global > variables" and I am not sure which you are referring to. > > One relates to the old-style register_globals property in php.ini being "on". > In this case, form input (GET or POST), cookie values. session variables, and > server values are turned into local PHP variables. For example an HTML form > could contain an input statement with a name property of "lastname". In PHP a > local variable would automagically be created called $lastname with the value > submitted by the form from the visitor. When register_globals is on, you don't > really know where the variables come from--they could be cookies, or POST or > even GET variables in the URL. It's an easy matter for someone to edit the > HTML of your form on their client machine, add form variables and values, and > submit it to your script. If you are not careful about validating which > variables come in or their acceptable values, you can have some serious > problems. Variables you use inside your program can be hijacked to values you > never intended. > > Most PHP installations have register_globals "off" (see the output of a call to > phpinfo()) to improve security. Under this situation, only variables on which > you take action will become part of the local variables for use in PHP. This > often involves accessing them from a specific input stream through the use of > "super globals" such as $_GET, $_POST, $_COOKIE, $_SERVER, $_SESSION, $_FILES. > In the case of the form variable above sent via POST, you would access the form > value with a statement like $_POST['lastname']. > > There are other variables like $GLOBALS and others, some of which are > combinations of $_GET, $_POST, and $_COOKIE. These are risky to use because > you no longer know where the information came from again. > > It is tedious to use references like $_POST['lastname'] so there are ways to > define simpler variables with their values. One way is to write something > like: > > $lastname = $_POST['lastname']; > > and repeat this for each variable you expect to use. If you have a very large > form with many input variables, you may consider this to be too tedious. > > If you only plan to accept input from POST you can use a statement like: > > extract($_POST); > > to make local variables from each form variable coming in via the POST method. > This exposes the problem of the end user editing a copy of your HTML form and > injecting new variables you didn't intend to receive. > > You can be more selective about which variables are turned into local variables > by defining the variables at the top of your program and using a variation of > the extract() function: > > $lastname=""; > $firstname=""; > $email=""; > extract($_POST, EXTR_IF_EXISTS); > > This example will only create local PHP variables of $lastname, $firstname, and > $email. They will have no value to begin with. If those form variables have > values coming in from POST, those values will be placed in variables which > already exist in your symbol table. Any other POST variables will be ignored. > The chances for abuse are reduced significantly. > > There are many other sources of problems. I have a small article which was > initially a presentation to a user group and is now something I use in some of > my classes. You can find it in (http://www.ITeachPHP.com) under the topic of > "Writing More Secure PHP Programs". It doesn't cover everything and my > solutions may not be the same as others would prefer but It will get yous > started in thinking about security in your PHP programs. > > James > > > James D. Keeline > http://www.Keeline.com http://www.Keeline.com/articles > http://Stratemeyer.org http://www.Keeline.com/TSCollection > > http://www.ITeachPHP.com -- Free Computer Classes: Linux, PHP, etc. > Spring Semester Begins Jan 31 -- New Classes Start Every Few Weeks. Community email addresses: Post message: [email protected] Subscribe: [EMAIL PROTECTED] Unsubscribe: [EMAIL PROTECTED] List owner: [EMAIL PROTECTED] Shortcut URL to this page: http://groups.yahoo.com/group/php-list Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/php-list/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
