[Phpmyadmin-devel] Removing of grab_globals

[Marc Delisle]

Sebastian Mendel a écrit :
> Michal Čihař schrieb:
> 
>> Hi all
>>
>> I thing we all agree on removal of this security evil script. Me and
>> Marc already had non public discussion on this topic, however I thing
>> it should go on this list, so lets start it again :-).
>>
>> Basically there is need for some function to grab required parameters
>> from request and clean up GLOBALS array in case of register_globals is
>> on.
> 
> 
> cleanup is already done in grab_globals

I am in favor of dropping grab_globals, because it's too difficult to secure and 
to prove that it's been secured.

> 
> 
>> I suggested to create some function like:
>>
>> PMA_grabParameter($name, $request, $sanitizing = 'none', $required =
>> TRUE)
>>
>> The request parameter might not be needed, but it's up to discussion.
>>
>> While Marc came with way how Moodle does it:
>>

Michal, I showed this Moodle example because you wanted to know what other 
products are doing. I am not advocating for their mechanism.

About PMA_grabParameter(), is the second parameter used for the origin of the 
variable, like GET, POST, COOKIE, SESSION?

>> Comments?
> 
> 
> // ifsetor() ;-)
> function checkRequest($name, $default = null)
> {
>     if ( isset( $_REQUEST[$name] ) ) {
>         return $_REQUEST[$name];
>     }
> 
>     return $default;
> }
> 
> i think in most cases PMA should use $_REQUEST directly and use one of 
> the above function only to set default values
> 
> using of $_REQUEST makes it more clear where this variable came from, 
> reminding the developer always to take care with this variables!

I don't understand why using $_REQUEST makes more clear where this variable came 
from. In $_REQUEST, variables can come from EGPCS, as defined by the 
variables_order directive. I think that it's better to say explicitly where we 
expect each variable to come from.

> 
> and i think its not good to always 'clean' variables
> 
> what will you clean of? you can not decide what users inserts into her 
> database or they name her tables and fields

We have many possible sources for an attack. An evident one is with the 
variables that are echoed back (partly checked with PMA_sanitize(), for example 
in sql.php. But there are other sources, like attacks on $_FILES.

> 
> you just have to take care to escape the input correctly before 
> inserting or displaying - but not cleaning!
> 
> and if the variable is a choice of options you have to check against the 
> original choices (in_array or array_key_exists)
> 
>