[LOW:KNOWN ISSUE:1.0.11] mosGetParam bug or not ?

[Trail]

For the better part of the day i was struggling to find a scoring problem in my joomlaflashgames gamehall running on j1.0.10.

i finaly traced it back to mosGetParam wich has been changed about a month and a half ago.

--- quoting syntax from API ---

mixed mosGetParam ( array &$arr, string $name [, mixed $default [, int $mask ]] )

$arr
is the array that the parameter will be retrieved from.  This can be any array but the most commonly used ones are $_POST and $_GET.
$name
is the name of the parameter field to be retrieved.

$default
is the optional default value that will be returned if $name is not present in $arr.  This parameter is optional and if omitted will default to null.

$mask
is an optional parameter containing one or more of the following flags:

_MOS_ALLOWHTML
Do not strip HTML tags from the data.

_MOS_NOTRIM
Do not remove leading and trailing whitespace characters.

_MOS_ALLOWRAW
Do not filter the data.  Introduced in Joomla 1.0.
If omitted this parameter defaults to 0 (that is, data will be stripped of HTML tags and leading and trailing whitespace characters).

--- end quote api ---

What exactly is ment with FILTER in _MOS_ALLOWRAW ?

Lets say i POST a score '100.99'

When i use:
$score = mosGetParam( $_POST, 'score',0);
I get $score=100 , but i used to get the full 100.99

When i use
$score = mosGetParam( $_POST, 'score',0, _MOS_ALLOWRAW )
I finaly get my $score=100.99 back

Now it could be me but .99 is neither a leading nor a trailing whitespace and a very important piece of my data..

Is this a bug ??

~Trail.

[Jenny]

Moving to the Quality and Testing 1.0x forum.

[friesengeist]

What exactly is ment with FILTER in _MOS_ALLOWRAW ?

Filter filters out all html tags and other stuff that might make your application vulnerable.
_MOS_ALLOWRAW (and for now also _MOS_ALLOWHTML) deactivate the filter.

Lets say i POST a score '100.99'

When i use:
$score = mosGetParam( $_POST, 'score',0);
I get $score=100 , but i used to get the full 100.99

In 1.0.10, a new security measure was introduced: If the default value is numeric, the input value will be converted to integer. So you either need to specify _MOS_ALLOWRAW or set the default value to e.g. false (and then take care of the value you receive by yourself).

[friesengeist]

Since this is already in Q&T:
From looking at the code, I think there is a missing negation...

Is:

Code: Select all

if (empty($return) && is_numeric($def)) {
	// if value is defined and default value is numeric set variable type to integer
	$return = intval($return);
}

Should be:

if (!empty($return) && is_numeric($def)) {
// if value is defined and default value is numeric set variable type to integer
$return = intval($return);
}

Haven't tested though...

[rickrrr]

Hi,

I have just run into this issue too, having just upgraded to 1.0.10.

The question comes down to, why would you want to change a return value into an integer based on the default value being numeric?  That is simply making too big an assumption.

We use "0" for a default a lot for non integer values.  Fine, in some cases we could change our defaults to null or false, but in the case
of floating point values that does not make sense.

As previously indicated, if you have values like 100.99 and you want a default of "0.0" (a resonable return when you are expecting a floating point value), making the return value an integer based on the fact that the default "0.0" is numeric, is completely wrong. Turning off the filtering is not a reasonable solution either, I want the filtering, that's the point of using mosgetparam.

I suspect this is going to break a lot of web sites.
We have dozens of instances that are now returning garbage as far as we are concerned.  I hope this will be treated as a bug and fixed.

[user deleted]

Q&T Note; posting to Dev list, asking for status on this report since a possible bug was found by Enno.

[user deleted]

Hi,

I have some feedback from the developers; although this can indeed be considered to be a bug, solving it will most likely break 3rd Party Extensions and we do not want to do this of course with the 1.0.12 being a stability release.

I'll therefor mark this as a known issue, and will move it to the corresponding forum.