PHP Server Side Scripting Forum

it is easy to use $_POST and $_GET instead. just put the variable name like echo $_POST['varName']; since it is an associative array so within a string you can use it like echo "{$_GET['varName']} welcome";

yes, absolutely

>> Can I get some feedback on how best to do this when using 'get' and 'post'?

you need to assign the variables from POST, GET or other explicitly to local variables. You can even use the as is $_POST['varname'] but I wouldn't suggest that. You need to make sure that these variables are safe/clean before using them in your code since they are all supplied by the user.

How you clean them will depend on what type of data is expected. You could look at this thread
PHP Security [webmasterworld.com]

>> which checks all the global arrays and get me the variable value

1) Huge security implications which forced PHP to ship with register globals defaulting to OFF starting at version 4.2.0

2) The feature will be deprecated with PHP 6.

very site specific and my answer would be "no you shouldn't"

>> the best solution is to use a source code version control system like CVS

disagree, for most this would be insanity

>> If you must store a password in a session variable (and I stress again that it's best just to avoid this)

then why give code to do it, just say "don't do it, ever". Then goes into a bunch about encryption that would be better spent on saving passwords to a db than saving them to a cookie, which again is not recommmended

>> The easiest way to protect against this is simply to escape the characters that make up HTML syntax (in particular, < and >)

a matter of opinion really, most of your user input shouldn't have tags in it at all and you should just rip them out, no problem

I know his bit on XSS essentially says, these other sites are better so read them, but I think that portion of his article assumes too much and could be misleading.

>> most particularly the single quotes ('). The simplest way to do this is to use PHP's addslashes() function.

well, he mentioned php 4.3 earlier and mysql_real_escape_string was available then and mysql_escape_string was what we muddled through with for a bit before that. Yes, that is db specific but it at least deserves a mention.

the next whole part about magic_quotes is out of place in the article and mainly wrong

The whole injection bit is just lean, it gives an image that isn't really the truth. A better and shorter way to say it would be to tell people to find out escape chars for their db and mainly just to make sure that all data is tested for what is expected and then run through a db safe function if one exists.

the whole data handling section is somewhat light. You could write a whole site on that alone but I thought it was just a bit off target, especially this part "Archive the data and store it offline, limiting the amount of data that can be compromised if your Webserver is breached", ah geez

overall the first page was good until we got to xss and then went downhill from there, the end was strong as the further reading was good.

A FREE, Volunteer article or post, I think, should be expected to have misleading information. Because a highly paid expert cannot spend hours to write an authenticated post or guideline for someone, it feels like some kind of overhead to them...