Is the undesirable conversion of a scientific number a vulnerability?

Question

I noticed in several penetration tests that PHP is converting values like 1e9 to 1000000000 while the max accepted string length of this number is 3 (in the database storage and as maxlength property on the HTML forms).

Nevertheless, when inputting 1e9 (3), PHP will return 1000000000 (10) as its output. That is a higher number than the application expects and can properly handle. Therefore I would consider a better validation of user input to prevent this.

Firstly, I assume this behavior is not dangerous but just undesirable, is it legitimate to assume this? Secondly, can I consider this as an actual (low severity) vulnerability?

Also the input 9e9 will result in the max 32-bit value 2147483647 (10) instead of 9000000000 (10). Is this alone (32-bit system or configuration) considered as leakage of system information or dangerous anyhow?

Answer 1

Strictly speaking? No, by itself it isn't a vulnerability. But it does suggest there's potentially a problem that needs further investigation.

This is one of the inherent problems with pen testing. You find something ambiguous like this, and don't know if it's exploitable. To even start to find out if this is a vulnerability, you need to understand what the input limitation does.

For instance, if the program was designed to limit bank transfers to under $1000 and the input field was the amount, and there's no further checks anywhere, you've just found a huge vulnerability.

On the other hand, if the field is just the first 3 digits of a phone number that creates a phone number database for parents to enter contact numbers for a school, and the validation is simply to make sure the user only input the first 3 digits, you've likely found nothing but a corner case where a very nerdy parent can screw up his/her own phone # entry in the database.

Answer 2

Why does this happen?

It's because PHP has loose typing. Take a look at this example:

$x = "1e6";
echo strlen($x); // 3
echo $x * 1;     // 1 000 000

On the second line, $x is assumed to be a string, and as such is obviously three characters long. On the third line, $x is interpreted as an integer, or 1 000 000 in this case.

Is it a problem?

This can definitely cause bugs, and every bug is a potential security vulnerability. But on it's own, it does not make your application vulnerable by default. But lets try to imagine a scenario where it would cause a problem.

Let's say a forum has numbered groups that users can freely join, but the first 10 groups (0 to 9) are reserved for administrators. The code for joingroup.php looks like this:

$group = $_POST['group'];
if(strlen($group) > 1 || $isadmin) {
    join_group($group, $uid);
}
else {
    // Fail.
}

You could sneak into an admin group without actually being an admin by posting e.g. 0.3e1, that has string length 5 but evaluates to 3. I know, it is a silly example. The point I want to make is that if you rely on strlen() (or anything else that treats the input as a string) to validate numeric data, you might be vulnerable.

Just posting 3.0 or  3 would bypass this check as well. For more on how PHP implicitly converts strings to numbers, check the manual.

How should I deal with this in PHP?

Validate user input. Check that you actually get an integer when you expect to get an integer:

if(!ctype_digit($group)) {
    // Fail.
}

It is also a good idea to always treat something that should be an integer as an integer and not a string:

$group = (int) $_POST['group']
if($group > 9 || $isadmin) {
    // ...

Is this leaking system information?

Apparently this can reveal the maximum integer value. Perhaps someone could deduce that you are using PHP from this, but there are probably many other ways to do that already. The max value is platform dependent, so it could be used for fingerprinting. But in practice 32 bits are probably used on a 32-bit system, and 64 bits on a 64-bit system. So that is the only information you are leaking.