05162005 1119 GMT-6
Marian, go get PHP for the World Wide Web by Larry Ullman isbn
0-321-24565-2. This book really saved me on some projects. Most
tutorials write scripts using globals on, as in
if($variable) {
// $variable is a submitted variable
}
Check out this book. It will greatly simplify your life.
Wade
James Keeline 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)
> <http://www.ITeachPHP.com%29> 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]
> <mailto:[EMAIL PROTECTED]>
>
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <http://docs.yahoo.com/info/terms/>.
>
>
>------------------------------------------------------------------------
>
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005
>
>
[Non-text portions of this message have been removed]
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/
