Picky, Picky, Picky ! 
A problem I have is the (code) tags turn the text into about 5 pixel high writing in MSIE, so I have to guess -- or change settings. Easy to miss things like that <G>
What Alex is saying about the quotes is very important!
You want to wrap the WHOLE SELECT statement in a set of double-" "and put each "value" based term into a set of single-' '.
You don't want to use ' ' around $value parameters that YOU SET in the script, only around things that are to be INTERPRETED or are passed by a user.
Ex:
$value = ' AND $column_name = 1';
You don't want to put '' around the $value, since you want that interpreted as a part of the overall SELECT statement. _BUT_ you need to make sure what you stuff in $column_name is _NOT_ user input, but something you PICK FROM A LIST based on the user input! (NO UNSAFE PROGRAMMING!)
On the other hand:
$value = $in->param('some_value');
you'd want to turn into '$value' after you did some checks on the data, so that when you used it:
$query = qq| " SELECT * FROM $table
$where
AND $column_name='$value' "|;
what will happen is the "" around the whole statement will pass the ' as strings, and not as special characters.
I think I got this right! -- Don't forget the " around the whole statement, as well as the ' around the _values_.
This still brings up a problem..... even with autoescape, and escaping, shouldn't you test the data to make sure it contains ONLY characters, numbers and underscore characters any way??
In search -- the only script that a value is passed in from the user and acted upon, the input is digested 10 different ways before it's used.
In the login script -- a user could potentially pass anything in as a username or password.
Anything you do should be preceeded by a test for anything out of the ordinary. Never trust any values passed by a user. If you are expecting one of 10 words, check for those 10 words specifically. If you are expecting only alpha-numerics check for a-zA-Z0-9_
The SQL engine adds another layer of complexity and potential security holes if an un-parsed un-escaped query can be passed, a hacker could get into your data base -- or sensitive data out of it.
A problem I have is the (code) tags turn the text into about 5 pixel high writing in MSIE, so I have to guess -- or change settings. Easy to miss things like that <G>
What Alex is saying about the quotes is very important!
You want to wrap the WHOLE SELECT statement in a set of double-" "and put each "value" based term into a set of single-' '.
You don't want to use ' ' around $value parameters that YOU SET in the script, only around things that are to be INTERPRETED or are passed by a user.
Ex:
$value = ' AND $column_name = 1';
You don't want to put '' around the $value, since you want that interpreted as a part of the overall SELECT statement. _BUT_ you need to make sure what you stuff in $column_name is _NOT_ user input, but something you PICK FROM A LIST based on the user input! (NO UNSAFE PROGRAMMING!)
On the other hand:
$value = $in->param('some_value');
you'd want to turn into '$value' after you did some checks on the data, so that when you used it:
$query = qq| " SELECT * FROM $table
$where
AND $column_name='$value' "|;
what will happen is the "" around the whole statement will pass the ' as strings, and not as special characters.
I think I got this right! -- Don't forget the " around the whole statement, as well as the ' around the _values_.
This still brings up a problem..... even with autoescape, and escaping, shouldn't you test the data to make sure it contains ONLY characters, numbers and underscore characters any way??
In search -- the only script that a value is passed in from the user and acted upon, the input is digested 10 different ways before it's used.
In the login script -- a user could potentially pass anything in as a username or password.
Anything you do should be preceeded by a test for anything out of the ordinary. Never trust any values passed by a user. If you are expecting one of 10 words, check for those 10 words specifically. If you are expecting only alpha-numerics check for a-zA-Z0-9_
The SQL engine adds another layer of complexity and potential security holes if an un-parsed un-escaped query can be passed, a hacker could get into your data base -- or sensitive data out of it.
