Page 1 of 2
String conversion to number
Posted: Wed Jan 03, 2007 5:08 am
by matthijs
Something I just discovered is that when you use an increment or decrement operation on a variable, that variable is converted to a numeric data type. So:
Code: Select all
<?php
$foo = 'some<string';
$bar = $foo +1; // $bar is now int(1)
?>
Considering the way PHP handles variables, that's not a real surprise now that I think about it.
The reason I found out was because I was working with this code:
Code: Select all
<?php
$index = isset($_GET["id"]) ? $_GET["id"]-1 : 0;
?>
Which I wanted to validate as being an integer. But trying several kinds of input I discovered that $index will never be anything else but an integer.
From the
PHP maual,
To explicitly convert a value to integer, use either the (int) or the (integer) cast. However, in most cases you do not need to use the cast, since a value will be automatically converted if an operator, function or control structure requires an integer argument. You can also convert a value to integer with the function intval().
See also
type jugling.
So, as it seems, the above code is enough to ensure $index is always an integer. However, I would like to know if there's anything I overlook. Is there a situation in which this is not true? Should I still use a cast (int) as an extra measure to ensure $index becomes an integer?
Posted: Wed Jan 03, 2007 5:17 am
by Ollie Saunders
As I understand it: The manual is correct and you don't need to worry.
Its like that thing people do:
Code: Select all
function foo() {
return 'foo';
}
function bar() {
return (bool)(4 > 1);
}
and I routinely ask myself, why have you put brackets around the expression and why the bool cast? The usage of > guarantees a boolean result. As '.' guarantees a string result as +1 guarantees an integer one.
Be aware ++ and -- however. They can operator on integers and strings (never tried on floats).
Code: Select all
$int = 1;
echo ++$int; // 2
$str = 'a';
echo ++$str; // b
Re: String conversion to number
Posted: Wed Jan 03, 2007 6:56 am
by Oren
matthijs wrote:Which I wanted to validate as being an integer. But trying several kinds of input I discovered that $index will never be anything else but an integer.
Anything which comes from POST/GET
is always a string - nothing else.
Re: String conversion to number
Posted: Wed Jan 03, 2007 7:09 am
by matthijs
Oren wrote:matthijs wrote:Which I wanted to validate as being an integer. But trying several kinds of input I discovered that $index will never be anything else but an integer.
Anything which comes from POST/GET
is always a string - nothing else.
Um, could you elaborate why you say this? I understand that everything from POST/GET is a string. But my question was about what happens with GET['id'] when it is cast to an integer by:
Code: Select all
<?php
$index = isset($_GET["id"]) ? $_GET["id"]-1 : 0;
?>
To be more specific:
- Can I be sure that $index will always be an integer? Or is there some exceptional case in which this isn't true?
According to the manual and Ole I can be sure that that is the case.
Posted: Wed Jan 03, 2007 7:23 am
by Oren
First of all, to make things more clear, I just wanted to make sure you know that anything from POST/GET is a string - I didn't say anything about ole's answer nor did I answer your question - all I was trying to do was to teach you and other people that might not know this (and I've seen such people).
Now to your real question, yes you can be sure, and yet I wouldn't do it for several reasons:
1. What if PHP's behavior will change in future versions?
2. I would sanitize any data which comes from the user first, and only then I would validate/check it (and yes, there is a different between the two).
3. Some people will argue, but I believe in "Better safe than sorry" - even in places where I myself believe it's not necessary to do X, Y and Z, I still do them as long as it doesn't require too much extra resources from the machine.
Re: String conversion to number
Posted: Wed Jan 03, 2007 7:47 am
by Ollie Saunders
Oren wrote:Anything which comes from POST/GET is always a string - nothing else.
Well...that was random. Are you OK Oren? I've got a cup of tea here for you

mmmm tea. Sugar?
I'm joking around of course.
1. What if PHP's behavior will change in future versions?
It would be marked as deprecated for a while first. You shouldn't not use features because of the chance it might be changed. If I did that would would I be left to use?! They might (in fact, I hope) deprecate using a $ to prefix all variables that doesn't mean I'm scared to ever declare a variable
2. I would sanitize any data which comes from the user first, and only then I would validate/check it (and yes, there is a different between the two).
Yes I've done that before. I'm pretty sure its a good technique. In fact here's the code:
Code: Select all
/**
* Returns the equality of value verus (int)$value
*
* @return bool
*/
public function int($value)
{
return (int)$value == $value;
}
3. Some people will argue, but I believe in "Better safe than sorry" - even in places where I myself believe it's not necessary to do X, Y and Z, I still do them as long as it doesn't require too much extra resources from the machine.
It's called "defence in depth" and yes it is a good idea. Personally I don't think you need to do it at comparison level but you are entitled to disagree.
Posted: Wed Jan 03, 2007 7:52 am
by matthijs
Oren wrote:First of all, to make things more clear, I just wanted to make sure you know that anything from POST/GET is a string - I didn't say anything about ole's answer nor did I answer your question - all I was trying to do was to teach you and other people that might not know this (and I've seen such people).
That's ok of course. I appreciate that. I just asked because your comment make it seem like I might have missed something (with the big red letters and all..)
Oren wrote:
Now to your real question, yes you can be sure, and yet I wouldn't do it for several reasons:
1. What if PHP's behavior will change in future versions?
I hope not too much

but you are right. Defense in depth.
Oren wrote:
2. I would sanitize any data which comes from the user first, and only then I would validate/check it (and yes, there is a different between the two).
I'm not sure I agree on this one. At least not in every situation. Normally, especially when it comes to form processing I don't want to sanitize the data, but instead validate the data and return a (friendly) error message when someone posts the wrong data. If someone registers on a forum and enters his username as somedude12! I wouldn't want to strip out the 12! without letting that user now.
However, in this specific case I use $_GET['id'] to page through several photo's. In that case I don't mind an id of '1abctest' being sanitized (by casting) to 1. But maybe we mean the same things but use the definitions differently.
Oren wrote:
3. Some people will argue, but I believe in "Better safe than sorry" - even in places where I myself believe it's not necessary to do X, Y and Z, I still do them as long as it doesn't require too much extra resources from the machine.
You are absolutely correct. So would you do it like this:
Code: Select all
<?php
$index = isset($_GET["id"]) ? (int)$_GET["id"]-1 : 0;
?>
Or is that synthetically wrong?
But even if I use several layers of security, I still want to be sure
each layer on it's own is doing what I think it should do. Therefore these questions. Thanks for your input.
Posted: Wed Jan 03, 2007 8:44 am
by Oren
matthijs wrote:Code: Select all
<?php
$index = isset($_GET["id"]) ? (int)$_GET["id"]-1 : 0;
?>
Or is that synthetically wrong?
I believe you can check this yourself
matthijs wrote:I'm not sure I agree on this one. At least not in every situation. Normally, especially when it comes to form processing I don't want to sanitize the data, but instead validate the data and return a (friendly) error message when someone posts the wrong data. If someone registers on a forum and enters his username as somedude12! I wouldn't want to strip out the 12! without letting that user now.
I'm sorry if I'm wrong but this makes me feel that you don't see the difference between "sanitizing" to "validating", am I correct?
Please give us more background about what you are trying to do, so we can answer your questions more properly.
Re: String conversion to number
Posted: Wed Jan 03, 2007 8:47 am
by Oren
ole wrote:Well...that was random. Are you OK Oren? I've got a cup of tea here for you

mmmm tea. Sugar?
I'm joking around of course.
I told you, I wasn't answering to his questions - I just tried to teach him and other people (that's why the big red letters) something that was related to his post in some way.
Posted: Wed Jan 03, 2007 9:38 am
by matthijs
I believe you can check this yourself
Of course and I did. Always nice to be sure.
oren wrote:I'm sorry if I'm wrong but this makes me feel that you don't see the difference between "sanitizing" to "validating", am I correct?
Well, to me:
Sanitizing:
cleaning up something. So if something - a string for example - contains something you don't like you strip that out and return the string without the nasty stuff.
Example:
Code: Select all
<?php
$taintedstring = 'abcd@#%'; // dirty stuff is @#%
$sanitizedstring = sanitize($taintedstring);
// $sanitizedstring is now 'abcd'
?>
Validating:
Making sure something contains what you expect/want it to be. For example a string should only contain alphabetical characters
Code: Select all
<?php
$taintedstring = 'abcd@#%'; // dirty stuff is @#%
if ( isValidString($taintedstring) ) // returns TRUE or FALSE
{
// if TRUE $taintedstring can be used
}
else
{
// if FALSE return error etc
}
So is this something you agree with or do you have other ideas about sanitizing/validating?
oren wrote:Please give us more background about what you are trying to do, so we can answer your questions more properly.
In this case I just wanted to know for sure if what I thought about the line of code was correct. The $_GET['id'] is used for paging through a gallery of photo's, so must only contain integers.
Posted: Wed Jan 03, 2007 4:23 pm
by Oren
Well
matthijs, I see you understand some of it, but not exactly.
In short, validating means checking that it plays by your rules according to what the data represents. An example is validating a username - in this case the data represents a username in you applications and you'd like to make sure it "plays by your rules" - as you define them for this specific application (e.g in one application a valid username will be [a-z] while in another application a valid username will be only the letters [a-g]).
Sanitizing (in a
brief), means making sure the data won't do any harm

Posted: Wed Jan 03, 2007 4:51 pm
by matthijs
Yeah, the terms and how they are defined and used by everybody varies a lot. Another term used by chris Shiflett is (input) filtering.
Well, I think the most important thing is that one should know what is going on. And why. (the why is something missing in a lot of writings, but that's another issue). Of course it helps in communicating when we all talk about the same things.
Posted: Wed Jan 03, 2007 5:07 pm
by Oren
matthijs wrote:one should know what is going on. And why.
True.
matthijs wrote:(the why is something missing in a lot of writings, but that's another issue)
True I guess
matthijs wrote:Of course it helps in communicating when we all talk about the same things.
Also true

Posted: Thu Jan 04, 2007 6:43 am
by Mordred
@
Oren:
Anything which comes from POST/GET is always a string - nothing else.
I'm sorry, you are mistaken, it could also be
an array, and that is a common way to find interesting messages with applications that fail to consider the possibility.
@Everyone:
Validating is nice for the user, but as a security-aware developer you should always filter/escape/sanitise/sanitize the input accordingly.
Filter if you want to be
secure,
validate if you want to be
nice.
Don't forget that every function that could be injected with user input requires its own filtering, don't fall in the magic_quotes/addslashes trap!
Posted: Thu Jan 04, 2007 8:16 am
by matthijs
Mordred wrote:Validating is nice for the user, but as a security-aware developer you should always filter/escape/sanitise/sanitize the input accordingly.
Mordred wrote:Filter if you want to be secure, validate if you want to be nice.
It's nice that you give us your point of view, but as we've seen so far everybody means something else when talking about input validating/../etc. You use several terms in one sentence, of which at least one (escape input?) doesn't seem correct. Would you like to expand on what you mean by them?
In my opinion validating, filtering and sanitizing, all used on input, are terms used for the same process: making sure only data you want can enter your script/application. Within that process several things can happen. Checking what the input is, returning an error or message, returning true/false, logging something, stripping data, etc etc. It all depends on the specific situation what should be done exactly.
Maybe it would be nice to use examples related to my original topic (integers) to stay a little bit on topic.