auto variable initialization from parameters

[fedoracore]

Hi there.

I've come across something in a PHP book from 2002 -- i think they establish that PHP 4 is the "current version".

there is no small amount of discussion regarding their claim that "..automatic variable initialization from parameters is one of the best features of PHP⁽¹⁾, but i've never known PHP to perform like that. I've been working with PHP since v.4.x but i probably wouldn't have encountered this particular topic anyway-- but i know it's not doing the "automatic initialization" here in PHP 5.1.6 (Fedora Core 5).

What is Automatic Initialization according to this book? it means, essentially-- any value sent via http GET is taken in by PHP and a variable is made. for example <?php
// value entered via URLwas:
// http://localhost/example.php?someVariable=2007

echo "The year entered is: ".$someVariable;
?>
(output, according to Book example:)
The year entered is: 2007
as far as i've ever known, this would cause an error of "undefined variable $someVariable", which i could "fix" by the following:
<?php
// http://localhost/test.php?someVariable=2007
if(isset($_GET['someVariable'])) {
$someVariable = $_GET['someVariable'];
} else {
$someVariable = "No Value Received";
}
echo "the Year is: ";
?>
(output, according to my knowledge:)
the Year is: 2007

my guess is that i can enable and disable this via setting now in PHP 5.1.6 in the php.ini file, but i don't know what to look for-- and maybe i'm wrong altogether.

what is it that i need to know here? i'm kind of surprised i've never heard of this before! (they go on to discuss the security issues, which would seem obvious-- but i just want to figure out "HOW" to get it going in the first place-- so i can follow the examples in the book, etc.)

thank you!!
(1)Web Database Applications with PHP and MySQL - Williams, Hugh and David Lane. O'Reilly. 2002

[CrYpTiC_MauleR]

That is register_globals its a serious security issue and should be turned to 'Off' i the php.ini file. A Google search for register_globals will yield more info and the security concerns about it. You should NEVER code using register_globals it was a mistake the PHP group made, and they regretted it and have since by default turned it off in newer versions. PHP 6.0 will actually remove it completely from PHP.

PS. you might want to get a much newer book, since that book is outdated and will teach you insecure coding and even use obsolete methods and functions. If you are learning PHP you should not learn from a source like that. The PHP.net online manual is by far the best book you can read, its always up to date and full of user comments to aid you.

[fedoracore]

that book is outdated and will teach you insecure coding and even use obsolete methods and functions. If you are learning PHP you should not learn from a source like that.

right on. i hear you on the outdated bit, but i'm not sure i'd agree w/ obsolete. i'm familiar w/ register_globals = off ... i thought my replies here would mention something from the .ini file-- i merely didn't realize the infamous setting is what THIS was (disappointing that it's not specified in the book, but i did skip the first 3 chapters, so maybe it's there...).
apparently, everything i've learned (via how-to's, or the manual) since 2005 has basically ignored the register_globals issue as being understood -- after all, doesn't the php 4 "php.dist" (default .ini) set to "off" by default? and the security issues are emphasized right there-- how it's deprecated, etc.

as for the book NOT being outdated-- don't get me wrong, i realize there are functions in php5 which don't exist in php 4, and vice versa-- but that's not really what this book is about. not to mention, probably 3 out of 5 of the low-budget hosting solutions might not even offer php 5-- so i try to learn both ways of doing things.
nevermind all that-- the real point is that what this book CAN teach me is how to efficiently structure a secure web database application, complete with user sessions and input validation-- and the primary element i'm seeking to improve upon-- building the right forms around a solid DBMS, so i might ultimately get a better hold on Web App-based retail inventory management (insert, update, delete) among many-to-many relationships.

i believe, an advantage from the start since it's in my hands, the book has value in terms of learning  technique, and general, good practice rules-of-thumb. i agree that there's a lot out there, certainly more up-to-date info-- but this "register_globals" thing is the only item which seemed unfamiliar, hence my inquiry so i can be on track w/ the "now". (i.e. following examples doesn't necessarily mean putting them into practice, etc.)

A book offers something that you typically can't find on-line-- a thorough study, start to finish, over a broad range of skills, terms, concepts, etc.-- all arranged in a logical process designed for the reader to absorb the knowledge most efficeintly-- not to mention the work of a good author, edited and published by a top-notch publishing company like O'reilly-- typically will apply more work to the load w/out more effort (simple machine analogy?). blah, blah..

Nevertheless, I can't deny that a book from 2002 does have its limitations.
If i haven't bored you to death already-- i'd like to ask for a recommendation. I want to learn how to develop solid applications for processing a retail inventory from the "backend" (i.e. so the 'manager' can add products, update prices and images, etc.), and so that users-- should we choose to do so-- may, via a shopping portal (shopping cart?) log on securely to either 1.) place an order via Credit Card, or 2.) place an order for Sales Associate follow-up.

thanks for the info on register_globals! it all makes more sense now. i'll just use my if(isset($_GET...) method for working around it. i'm glad i encountered this-- i feel good about knowing as much about the .ini (and .conf) settings as possible. it helps!
i look forward to your replies-- and hopefully some book recommendations.

[VGR]

In fact, there has always been (and yes, it's new compared to PHP 3 /FI) an "EGPCS" order for assigning parameters values to global variables. The register_globals option was on by default. This is very useful, in that you control the order for the variables to "supercede" synonyms (ex. a GET parameter forced to toto=1 won't supercede the POST value of "toto" if the EGPCS order is this way : environment, get, post, cookie, session) : the POST one has "priority".

the faint troubles introduced by would-be hackers have led the PHP people to be super-cautious and they turned register_globals to Off by default. Some people took this as a recommendation to turn register_globals to Off. Now you'll find "security warnings" everywhere about this fuss. A lot of newcomers are artificially made afraid of register_globals.

I've always used register_globals=On and I'm no monkey. Just be careful when accepting user input data, as usual.

[nicholassolutions]

In fact, there has always been (and yes, it's new compared to PHP 3 /FI) an "EGPCS" order for assigning parameters values to global variables. The register_globals option was on by default. This is very useful, in that you control the order for the variables to "supercede" synonyms (ex. a GET parameter forced to toto=1 won't supercede the POST value of "toto" if the EGPCS order is this way : environment, get, post, cookie, session) : the POST one has "priority".

the faint troubles introduced by would-be hackers have led the PHP people to be super-cautious and they turned register_globals to Off by default. Some people took this as a recommendation to turn register_globals to Off. Now you'll find "security warnings" everywhere about this fuss. A lot of newcomers are artificially made afraid of register_globals.

I've always used register_globals=On and I'm no monkey. Just be careful when accepting user input data, as usual.

I'm not sure I agree. It's certainly possible to code a truly secure script with register_globals on, but you need to know what you're doing. Most beginning programmers -- when it comes to PHP -- are monkeys. They have usually not had enough experience to foresee all the issues involved, and their test of whether they did things "right" is whether or not the script "works". There are many scripts that "work", yet are very insecure because of this. Unfortunately, many are also open source, so anyone can easily read through the code and find the vulnerabilities for themselves - they don't even have to experiment on the server where the script is running. This isn't to say that turning register_globals off makes you write scripts that are 100% secure, but it does reduce the chances of including gaping security holes that anyone with half a brain could exploit.

Regardless of your opinion on the security, though, there are better reasons not to write code that depends on register_globals. First, since it is off by default, and people do regard it as risky, people will be less likely to use your script if you are distributing it, and many people will be unable to since they do not have control of the php.ini settings. Likewise, as Nick mentioned, they're planning on phasing-out the setting altogether in future versions, which means your scripts will not work in the future without re-coding them to meet the current standards. You're better off just doing that from the start.

[fedoracore]

hey thanks for all the discourse on register_globals-- indeed, an interesting argument...

but WHOA!
:)

for the record, i had no intent on trying to learn a technique which uses register globals "on". i have inserted my own code to create the same thing they're doing. they want to send variables via URL-- so i'm just putting them in the code. no big deal. i know what's going on, so it really makes no difference. (i think i mentioned about the little if(isset($_GET['... bit where i essentially cover it up-- purely for the sake of moving through the examples, of course-- to see the "grande scheme" as intended by the author, in other words (excepting those "lessons" in which to learn the register_globals function itself is the intent of the execise-- those i just skipped over...)
;)

ANYWAY...
now that we've got that covered -- (respectfully, if you please...) -- what about any recommendations for a good "learn to develop inventory based web applications" book? i'm not certain i am liking this book after all. though it's NOT all bad-- but i am concerned that i see a trend of yesterday's procedures, and technique (such as an "older" if...endif" syntax, and other stuff...

thanks!
:)

[VGR]

an "older" if...endif ? It's just a matter of style :D tell that to ASP/VBS people ;-)

[fedoracore]

an "older" if...endif ? It's just a matter of style :D tell that to ASP/VBS people ;-)

you went over my head on that one.  :confused: :shrug:

...but by "older", i'm referring to the following contrasting "PHP" syntax:

Code:

if (test expression)
{
(something happens)
}
else
{
(something happens)
}

versus

Code:

if(test expression)
(something happens)
if(test..)
(someting happens)

[CrYpTiC_MauleR]

thats just different coding conventions. Its best to use the first example since its more widely accepted and code looks cleaner and easier to read once properly indented. Here is a nice convention to follow http://www.dagbladet.no/development/phpcodingstandard/ should cover most commonly used practices and best methods.

[fedoracore]

when i first realized the difference in "the book", from my own convention, i decided to do a bit of research, and found a little snippet of PHP History which i found useful as well. most of which is probably "common knowledge" to PHP programmers, but some of it i didn't know. :)

Here is a nice convention to follow http://www.dagbladet.no/development/phpcodingstandard/

hey, thanks!

myself, i've followed this convention for "the longest time", but lately, i've been putting in the extra line break (as i illustrated above) because i find that the IDE / text-editor code-folding tends to favor that convention-- some won't fold w/out it

okay-- so i've got that "Refund" comin' here in a few weeks-- and i'm all about looking at www.oreilly.com
according to my "History" file, i was looking at:

• Essential Action Script
  
• Dynamic Apache w/ Ajax
  
• Facelets
  

and several others which aren't in the History! hehe...
but-- you get the idea? thing is-- there's SOOO many for PHP, probably many a few years old which are still incredibly good references-- and that's where i'm stuck, and why i have posed this question. for example, when PHP5 first came out, was there one "Quintessential" book i might want to look into buying? (other than the manual, of course!) remember-- we're talking about applied theory here-- that's what i want to investigate.

 i happen to have Flash 8 Pro, so i "can go there" if i choose, and a i've already felt the tugging on my arm for me to go there from one of my clients-- but, if i truly had my choice-- it wouldnt' be on the top of my list because Flash doesn't interest me. but that's a whole other story.

right now, i want simple, solid, reliable-- powerful, e-commerce inventory management. i came a long way on a current app-- but i started having snags on the many-to-many relationships when it came to user input-- (for adding new items, new manufacturers, new colors of items, etc., etc.), so i decided -- it's time to read a good book. (realizing of course that those above aren't what i want for that, but they looked interesting, so i'm sharing! -- plus there's that "buy 2, get one free deal!!" ;-)

[VGR]

about if coding style...

the goal IMHO is to have clean, clear and maintainable code. So open a block only if you need it, and use two lines only if you need it.

thus :

if (test) perform_this; else perform_that;

if longer :
if (test) perform_this();
else perform_that();

if a block is necessary :
if (test) perform_that();
else {
  perform_that_1();
  parform_that_2();
} // if


etc

it's strictly the same as in school when you learnt :
if test then perform_this() else perform_that();

or

if this then perform_this();
else begin
  perform_that_1();
  perform_that_2();
end; // if

indenting with TAB is a bad idea IMHO
indenting more than two characters is also a loss IMHO

the goal is ***also*** to have compact code , not spanning 10000 lines if you can make it 100.
(not counting useful comment lines and staying away from "one-liners" à la C )

[Esopo]

About coding standards and the IF statement,

I settled a long time ago on using the brackets as if they were required, for readability sake and to help avoid those little casual mistakes. Not that I'm suggesting it should be a standard among all programmers and languages. I recently saw some Perl code that didn't make any sense to me, but I'm sure the guy who wrote it reads it just fine. Just a couple of weeks ago I heard a Perl programmer say something like “oh, the beauty of Perl!, I just wrote a line 200 chars long that would have taken at least 5 lines in any other language”. My immediate reaction was: why? I mean, if you can separate it into 5 decent lines, why make it a mess?, his reply was “it's easier to read that way”. - I'm not gonna argue with that, but to each his own.


My average if statement would look like this: (taken straight out of a page I'm working on):

//set the page to display
if (isset($_GET['pag'])){
  $pag = $_GET['pag'];
}else{
  $pag = 1;
}

Sure it could all fit into one line, but I've noticed that writing it like this makes it easier/faster for me to read it later, and it doesn't take much more work.



About register_globals,

I remember to me it was one of the coolest features back in 2000 when I was writing my first PHP scripts, but these days I have to say we are much better off not having it. Again, not that I want to say your style is any less usable VGR, but it does make it very easy to make mistakes and requires extra care not to leave openings.



About PHP books,

I ordered a bunch of .Net books a few weeks ago and I stopped to realize that although the language I work with the most is PHP, I don't own a single book on the subject. I have several books on just about everything else, but not a single one on PHP.

This is probably because PHP was easy to pick up, it has been my main language for a while, and the on-line resources have always proven more than sufficient.

I couldn't recommend any books, but perhaps other people can:

http://www.amazon.com/Recommended-Titles-for-PHP-Developers/lm/32X5DRYOPJZSB

[rdivilbiss]

Actually since you are talking about best practices for an inventory system:

Code:

<?php
// http://localhost/test.php?someVariable=2007
    if(isset($_GET['someVariable'])) {
        $someVariable = $_GET['someVariable'];
    } else {
        $someVariable = "No Value Received";
}
    echo "the Year is: $someVariable"; // <-- Is a XSS flaw.
?>

That should be:

Code:

<?php
// http://localhost/test.php?someVariable=2007
    if(isset($_GET['someVariable'])) {
        $someVariable = filter_input(INPUT_GET, 'someVariable', FILTER_SANITIZE_INT);  // PHP 5 > 5.2.0
    } else {
        $someVariable = "No Value Received";
}
    echo "the Year is: htmlspecialchars($someVariable"); // <-- Now is filtered, but you still should do htmlspecialchars() on output.
?>

You must filter all input and escape all output. Period.

While we are assuming an integer value of a year being passed, the code may change in the future.  So by not escaping the output, in the future in we change the input type we must assure the  subsequent developer is aware of the possible need for escaping.  Better never allow unescaped output in the first place.

Now, its rare to find a host running PHP 5.2.0 or greater, so you need some other input filter.  Also the current filter only does some basic types, and really doesn't deal with commonly used input fields, such as phone numbers, dates, addresses, valid file paths, etc. so I humbly suggest something like the PHP filter class I've posted in the Article wiki here.

http://www.expertsrt.net/main/components/com_mambowiki/index.php?title=PHP_Form_Filter_Class

Since it is in use by many and in the wiki, you can watch that page, in case better information comes along or a vulnerability is found.  Then your code would look like this:

Code:

<?php
// http://localhost/test.php?someVariable=2007
require_once('filterClass.php');
$rgetVars = new requestGet();
$someVariable = $getVars->getVarByType("REMOTE_ADDR", $type="int");
if (isempty($someVariable)) $someVariable = "No Value Received";
echo "the Year is: htmlspecialchars($someVariable");  // <-- You really need to set the pages charset and also use that here.
?>

Which is actually shorter code as you don't need the isset, it will be handled by the filterClass.

As to the forms and database interactions you'll need I offer:

Secure web forms
http://www.expertsrt.net/main/components/com_mambowiki/index.php?title=Building_Secure_And_Standards_Compliant_Web_Forms

and

MySQL prepared statements, as the techniques, functions and methods provided in those libraries are very good protection against many common attack vectors.
http://www.expertsrt.net/main/components/com_mambowiki/index.php?title=PHP_MySql_Prepared_Statements_Library

Concentrate on your business logic, e.g. making the inventory system function, rather than worrying about adding security in the business logic; e.g. let the functions and classes protect you, and you have only one place to make a change if a security issues is found.

Prepared statements are also called bound parameters or parameterized SQL depending on the database used.  These are your best protection against SQL injection attacks. 

So if you filter input, escape output and stop SQL injections you have eliminated over 90% of the most common PHP attack vectors/vulnerabilities.

Adding the form security, such as one type use tokens and encrypted form states eliminates just about all the rest.

(You can always have a logic vulnerability, if humans are programming the system.)

Regards,
Rod

[CrYpTiC_MauleR]

http://ha.ckers.org/blog/20070327/htmlspecialchars-strikes-again/ not as safe as PHP leads us to be.

For this circumstance this would be shortest and failsafe method.

<?php

// http://localhost/test.php?someVariable=2007
echo 'The year is: ';
echo (isset($_GET['someVariable']))
    ? (int)$_GET['someVariable'] // Typecast it to an integer
    : 'No Value Received';

?>

[rdivilbiss]

http://ha.ckers.org/blog/20070327/htmlspecialchars-strikes-again/ not as safe as PHP leads us to be.

I certainly did not suggest htmlspecialcharacters was a panacea....I'm well aware it is not; and I am on record saying so.  Setting the correct charset, and filtering input is still required, as rsnake mentions. Furthermore the idiot that wrote the article is using htmspecialcharacters as an input filter not as output encoding, which is what it is for.  I have never in my life suggested an output encoding function has any place as a input filter.

Typecasting may be sufficient in this simple case; but the discussion at large involves many different data types, which is why I brought up various filtering methods.

If you have filtered your input, you should still use htmlspecialcharacters on your output.

I may allow on my math blog 5 < 9 or y > x.  By doing so I accept the risk of allowing those characters in my input but will want to encode before output.

Absent writing your own, possibly even more flawed encoder, I am going to suggest using htmlspecialcharacters as part of a complete set of data safe practices.  Unlike many, including the idiot who wrote the article rsnake mentions, I have never said htmlspecialcharacters (alone) will make any data safe.

If you have set the pages charset and filtered your input, it is however a valuable addition to your solution.  If you have not filtered your input or set the charset then it is possible to carefully craft XSS that will pass htmlspecialcharaters, which is exactly what rsnake was pointing out.

It is perfectly functional when used for its intended purpose, output filtering, but is insufficient alone.