| 1:34 pm on May 12, 2006 (gmt 0)|
Two ways to pass your variable to your query:
A) Select * FROM table WHERE field='".$_POST['querystring']."'
$myvar = $_POST['querystring']; and thus
Select * FROM table WHERE field='$myvar'
Notice the difference in (') and ('") in the two examples
| 2:13 pm on May 12, 2006 (gmt 0)|
Query-string variables are automatically put into an array called $_GET to be extracted at your leisure. It's so simple it's scary. Maybe that's what's confusing you.
| 3:17 pm on May 12, 2006 (gmt 0)|
the php documentation [php.net] can tell you about it
Predefined variables [php.net]
let's use your example
you could access the value of the variable id in the $_GET array like so
this would output "myname". It is common to pull these into a local variable such as
$myid = $_GET['id'];
this would be the some syntax for any var in your url, take this example
$myid = $_GET['id'];
$start = $_GET['start'];
$section = $_GET['section'];
these vars could then be used to do whatever you need
1. for security purposes, check all variables when they come in, any user can change the GET string and give out of range or erroneous data
2. Read through using register_globals [php.net]
3. as you mentioned, GET strings, especially with params called id or PHPSESSID are no good for SEO
4. don't pass too much data in your GET string, there are limits, they are fairly large but try to keep it short and sweet
does that help a bit?
| 4:32 pm on May 12, 2006 (gmt 0)|
|for security purposes, check all variables when they come in |
This is the most important part. Always check whats coming in. Most script vulnerabilities start with unsanitized data from query strings.
| 5:08 pm on May 12, 2006 (gmt 0)|
Thanks a lot everyone! I 'GET' it now (har har har)!
| 6:55 pm on May 12, 2006 (gmt 0)|
Okay just a quick follow-up on the subject of security. My script only takes 1 variable (let's call it 'myVar' for demonstrational purposes) which is retrieved from the URL using the $_GET superglobal. I've created a test using a regular expression to make sure the value of myVar is what I expect it to be (only contains 2 digits and nothing else). And I've created a test to make sure that myVar actually exists in the URL passed to the script. Is that good enough? Is it possible to inject other variables altogether using a query string? What else -if anything- should I be aware of?
| 7:02 pm on May 12, 2006 (gmt 0)|
For example, how can I make sure that no other variables except myVar are injected using the query string in the URL?
| 7:12 pm on May 12, 2006 (gmt 0)|
those 2 tests should be fine
as long as you don't have register_globals on then nothing else gets automatically brought in
whether off or on if you initialize all of the vars you use they will always start off empty
| 8:47 pm on May 12, 2006 (gmt 0)|
Okay great. One last thing.. (sorry)... I've read through several pages from various sources on the net about 'initialising variables' and I'm still a little fuzzy on the concept. From what I understand, initialising a variable simply means assigning it a value in the actual script itself so that it can't be hijacked by malicious query string? Something like that? Is this correct?
| 10:29 pm on May 12, 2006 (gmt 0)|
initializing means you set them to a default value of the proper type before you use them, not specifically for security but it definitely helps with it
$myvar = '';
$myvar = 0;
$myvar = array();
$myvar = false;
or what have you, from a security standpoint this stops variables from having unknown values or allowing input to change their starting value/state.
| 9:29 pm on May 14, 2006 (gmt 0)|
Not sure I follow Adam.
If I have register_globals on and someone types in
that will set/reset $my_var to 3. Initializing variables doesn't change that one way or the other (that's why having register_globals on is such a major pain).
On the other hand, if register globals is off, nobody will be able to use a URL to reset a variable outside the superglobal arrays, whether initialized or not.
I think initializing variables is good practice and contributes to stability and avoids unexpected results, which contribute indirectly to security, but with respect to injecting values into the script I don't see a security advantage.
From a security and stability point of view I think the key thing is making sure that the values sent are of the type and in the range of what you expect. Testing for a two-digit integer is a fairly strict test, so that seems pretty good.
| 3:10 pm on May 15, 2006 (gmt 0)|
I actually don't think that is the case
would mean at script start $my_var would have a value of 3
if you set
$my_var = 0;
at the top of your script it isn't going to be set again to 3 it will be 0
that was my understanding, that vars are imported into the local variable table at start of execution, if you reset them then they would be whatever you wanted.
though I haven't used anything with register_globals on in a long long time.
| 4:22 pm on May 15, 2006 (gmt 0)|
ok I went and read through this page to make sure I wasn't losing my mind (always a possibility)
if you look at Example 29-1 this line comes below the code
|in our example above we might have first done $authorized = false. Doing this first means our above code would work with register_globals on or off as users by default would be unauthorized. |
so yes, proper initializattion of all internal vars will stop variable poisoning due to register_globals being on
and later on
|Of course, simply turning off register_globals does not mean your code is secure. For every piece of data that is submitted, it should also be checked in other ways. Always validate your user data and initialize your variables! To check for uninitialized variables you may turn up error_reporting() to show E_NOTICE level errors. |
| 12:22 am on May 18, 2006 (gmt 0)|
Ooops. Yeah that's obvious upon reflection. I just had some memory of being asked to fix a script and found the problem was variables being rewritten unexpectedly and it came down to a register_globals problem. It may have been because sessions vars were beign registered too and there were session vars and POST vars that unintentionally had the same name or some such nonsense.
| 3:00 am on May 18, 2006 (gmt 0)|
>> session vars and POST vars that unintentionally had the same name or some such nonsense
man, I have had to deal with that too many times
>> upon reflection
hehe, I had to go back and read it all to be sure, it would be far from the first time I was wrong and you were right ;)
| 3:36 pm on May 18, 2006 (gmt 0)|
For anyone starting out like littlegiant, I can't stress how much time some of these time-saving shortcuts like turning on register_globals will cost you. Definitely turn off register_globals and I would also say that if an open source script does what you want, but requires register_globals on to function (becoming more and more rare), find something else.
I'm glad that by the time I discovered PHP, I had a couple of advantages in that
- the PHP community had mostly progressed to turning register_globals off as a matter of standard and habit.
- I had a limited but sufficent background in C++ and Pascal to give me a negative attitude toward globals and uninitialized variables
That meant that I just haven't had to deal with the variable overwriting and other headaches that much.