Re: [PHP] Re: Select and $_POST
Curt Zirzow wrote: There is a pecl extension that you can register, custom superglobals although it comes with some extra stuff as well: http://php.net/runkit I wish it would be a part of core distribution. Would be extremely useful. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Select and $_POST
On Thu, Nov 10, 2005 at 05:21:51PM -0500, Ben Ramsey wrote:
> On 11/10/05 4:48 PM, Richard Lynch wrote:
> >Here's an idea... Quite possibly half-baked.
> >
> >Suppose PHP had a superglobal $_CLEAN which was an empty array.
> >
> >Further suppose it was documented in the manual as *the* place to put
> >your scrubbed data.
> >
> >This rather small and hopefully inexpensive change (in terms of PHP
> >Dev/Docs team work) would quite possibly improve scripts by newbies,
> >simply by nudging them in the proper direction, because it would be a
> >documented feature, and it would have all the nifty cross-links in the
> >manual and all that.
> >
> >It would also help to keep code cleaner to have $_CLEAN be a
> >superglobal rather than just something I made up and have to declare
> >as "global" all the time.
> >
> >Comments? Suggestions? Derogatory remarks?
>
> There is an Input Filter PECL extension that's still in beta, and I
> think it's a good step, though I'm not so sure about some of the
> sanitizing it performs. It doesn't offer the superglobal you're
> suggesting, but it probably wouldn't be too difficult to put it in there.
There is a pecl extension that you can register, custom
superglobals although it comes with some extra stuff as well:
http://php.net/runkit
> The only issue I see with building in a superglobal to the language (or
> this extension) is that it doesn't force the user to instantiate the
> empty array at the top of the script. This could make for a lazy
> developer, and, if s/he's not careful, anyone running the application on
> a machine in which register_globals is turned on would run the risk of
> having a potentially tainted $_CLEAN array, which defeats the purpose of
> the clean array altogether. The point is that the developer should be
> able to trust the data in $clean.
I think the idea would be that $_CLEAN is protected from anything
but your own code assigning a value to it, and will always be an
empty array. I'm not sure that will stop anyone from abusing it
and just stick $_REQUEST['password'] into the array without really
cleaning it.
The other issue with having a system variable like this, is if i
choose to not use it, perhaps i have a different method of
sanitizing my input, the variable just becomes an empty useless
item.
>
> If PHP had a taint mode and didn't have register_globals, then we'd be
> making some progress.
hmm.. an E_TAINTED error, that might be something good to have put
in php6, since register_globals appears to be going away then. I
could forsee some though code like this though:
array_walk_recursive($_REQUEST, create_function('&$v,$k', '$v = $k'));
Curt.
--
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Select and $_POST
On Thu, November 10, 2005 4:21 pm, Ben Ramsey wrote:
> On 11/10/05 4:48 PM, Richard Lynch wrote:
> The only issue I see with building in a superglobal to the language
> (or
> this extension) is that it doesn't force the user to instantiate the
> empty array at the top of the script. This could make for a lazy
> developer, and, if s/he's not careful, anyone running the application
> on
> a machine in which register_globals is turned on would run the risk of
> having a potentially tainted $_CLEAN array, which defeats the purpose
> of
> the clean array altogether. The point is that the developer should be
> able to trust the data in $clean.
I specifically stated the $_CLEAN "was an empty array"
By that I meant that $_CLEAN is initialized (by PHP core code) to be
an empty array, as part of the initialization routine that sets up
$_SERVER and sometimes $_POST/$_GET/$_COOKIE.
$_CLEAN would start as an empty array in all PHP setups (Module, CGI,
CLI, whatever) regardless of any other condition, pre-condition,
php.ini setting, or phase of the moon. :-)
--- unit test
--
--- expected output --
array(0) {
}
--
I wouldn't be too keen on it being only done as part of some PECL
extension that may or may not get loaded, particularly as the order of
loading of PECL extensions then would have an effect, I should
think...
PS
The problem with any generic/modular Input Filtering is that one is
never too sure about some of the sanitizing it performs.
There are simply too many application-specific sanitization "gotchas"
that make this something that is almost always best re-written from
scratch each time, imho...
Not that you don't re-use and cut-and-paste, but maybe in this one
email can be blank, but not in that one, or whatever. Too many
variables, and I've never seen (and can't really imagine) a good clean
modular way to handle this without being so damn complex it's
unwieldy.
--
Like Music?
http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Select and $_POST
On 11/10/05 4:48 PM, Richard Lynch wrote: Here's an idea... Quite possibly half-baked. Suppose PHP had a superglobal $_CLEAN which was an empty array. Further suppose it was documented in the manual as *the* place to put your scrubbed data. This rather small and hopefully inexpensive change (in terms of PHP Dev/Docs team work) would quite possibly improve scripts by newbies, simply by nudging them in the proper direction, because it would be a documented feature, and it would have all the nifty cross-links in the manual and all that. It would also help to keep code cleaner to have $_CLEAN be a superglobal rather than just something I made up and have to declare as "global" all the time. Comments? Suggestions? Derogatory remarks? There is an Input Filter PECL extension that's still in beta, and I think it's a good step, though I'm not so sure about some of the sanitizing it performs. It doesn't offer the superglobal you're suggesting, but it probably wouldn't be too difficult to put it in there. The only issue I see with building in a superglobal to the language (or this extension) is that it doesn't force the user to instantiate the empty array at the top of the script. This could make for a lazy developer, and, if s/he's not careful, anyone running the application on a machine in which register_globals is turned on would run the risk of having a potentially tainted $_CLEAN array, which defeats the purpose of the clean array altogether. The point is that the developer should be able to trust the data in $clean. If PHP had a taint mode and didn't have register_globals, then we'd be making some progress. -- Ben Ramsey http://benramsey.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Select and $_POST
On Wed, November 9, 2005 7:15 pm, Chris Shiflett wrote: > Ben Ramsey wrote: >> $clean = array(); >> $sql = array(); Here's an idea... Quite possibly half-baked. Suppose PHP had a superglobal $_CLEAN which was an empty array. Further suppose it was documented in the manual as *the* place to put your scrubbed data. This rather small and hopefully inexpensive change (in terms of PHP Dev/Docs team work) would quite possibly improve scripts by newbies, simply by nudging them in the proper direction, because it would be a documented feature, and it would have all the nifty cross-links in the manual and all that. It would also help to keep code cleaner to have $_CLEAN be a superglobal rather than just something I made up and have to declare as "global" all the time. Comments? Suggestions? Derogatory remarks? PS What does Chris Shifflett use to validate an email? Enquiring minds want to know! :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Select and $_POST
M wrote:
$clean['pass'] = md5((ini_get('magic_quotes_gpc') ?
stripslashes($_POST['pass']) : $_POST['pass']));
or users with quotes in their password won't be able to log in.
This is best handled in one place, so that it's easier to maintain and
less likely to be overlooked. In the examples provided, $_POST['pass']
is the password provided by the user.
Chris
--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Select and $_POST
Chris Shiflett wrote:
Ben Ramsey wrote:
$clean = array();
$sql = array();
Glad to see someone spreading this habit. :-) Thanks, Ben.
if (ctype_alnum($_POST['pass']))
{
$clean['pass'] = $_POST['pass'];
}
I think it's fine to cheat a bit with the password and trust the output
format of md5():
$clean['pass'] = md5((ini_get('magic_quotes_gpc') ?
stripslashes($_POST['pass']) : $_POST['pass']));
or users with quotes in their password won't be able to log in.
$clean['pass'] = md5($_POST['pass']);
Of course, it is best to use a salt:
$salt = 'SHIFLETT';
$clean['pass'] = md5($salt . md5($_POST['pass'] . $salt));
Chris
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Select and $_POST
Ben Ramsey wrote:
$clean = array();
$sql = array();
Glad to see someone spreading this habit. :-) Thanks, Ben.
if (ctype_alnum($_POST['pass']))
{
$clean['pass'] = $_POST['pass'];
}
I think it's fine to cheat a bit with the password and trust the output
format of md5():
$clean['pass'] = md5($_POST['pass']);
Of course, it is best to use a salt:
$salt = 'SHIFLETT';
$clean['pass'] = md5($salt . md5($_POST['pass'] . $salt));
Chris
--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Select and $_POST
On 11/9/05 6:21 PM, Ross wrote:
What is the correct syntax for
$query = "SELECT * FROM login where username='$_POST['username']' AND pass
='$_POST['pass']'";
Thought this would work.
R.
The correct syntax in this case is actually:
$query = "SELECT * FROM login where username='{$_POST['username']}' AND
pass='{$_POST['pass']}'";
Note the curly braces.
BUT! Never do this!
For example, consider if someone typed in their username like this:
foo' AND 1=1 --
The "--" in most database engines starts a comment, so the query would
end up being:
SELECT * FROM login where username='foo' AND 1=1 --' AND pass=''
Everything after the "--" is ignored. There doesn't have to be a user
named "foo" because 1 will always equal 1, so the user is instantly
logged in.
Instead, filter your input (data received) and escape your output (in
this case, data going to the database), and try something like this:
$query = "SELECT * FROM login where username='{$sql['username']}' AND
pass='{$sql['pass']}'";
?>
Everything in $_POST should be treated as tainted data. Everything in
$clean can be treated as valid and untainted. This ensures that the
username and password received only contain values that you expect. You
can modify the filtering to suit your needs. Then, it ensures that data
sent to the database in the SQL statement is always escaped so that it
doesn't try to do something it shouldn't.
This, of course, assumes you're using MySQL, but there are other
escaping functions for other databases. Just look in the PHP manual.
--
Ben Ramsey
http://benramsey.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
