By turning magic quotes off in my php.ini i can see that moodle is doing an array_map to $_POST, $_GET, $_REQUEST and adding slashes to all form information via a user function named addslashes_deep().
My first question is: Why has moodle devlopment supported a depreacted feature of PHP since PHP 5.3.0 as we are now on 5.2.9 this is just round the corner - See: http://uk3.php.net/magic_quotes
My second question is. I have defined a constant named MOODLE_SANE_INPUT in my config, so that moodle v1.9.2 does not attempt to quote the inputs. This makes me security concious because moodle components such as the Forum that does form processing may not be sanitising the databse input as it may assume magic quotes is on, or that addslashes_deep() has been called on them.
Hope to have a response from a moodle developer soon enough.
Thanks.
Yes, addslashes up until 1.9 was a horrible mess, and there was great rejoicing when the DB layer was completely rewritten for 2.0 to make it unnecessary.
But while 1.9 was a mess, the code was carefully reviewed, and was actually secure. It was just a pain to maintain.
Note, it is magic_quotes that is insecure. That is, expecting PHP to do wierd stuff for you, and allowing your web site to be hacked if that is off. Moodle was intentionally implementing its own security mechanism. Adding slashes to all input (irrespective of PHP's settings) was one part of that. Our required_param/optional_param was part of that.
If you get rid of the addslashes call, you will be making your Moodle completely insecure.
But while 1.9 was a mess, the code was carefully reviewed, and was actually secure. It was just a pain to maintain.
Note, it is magic_quotes that is insecure. That is, expecting PHP to do wierd stuff for you, and allowing your web site to be hacked if that is off. Moodle was intentionally implementing its own security mechanism. Adding slashes to all input (irrespective of PHP's settings) was one part of that. Our required_param/optional_param was part of that.
If you get rid of the addslashes call, you will be making your Moodle completely insecure.
Hi Tim.
Thanks for the quick reply.
Yes i realised that the core components would be relying on the magic_quotes or the addslashes_deep() functionality to escape the input.
Therefore i had to keep your escaping mechanism on, even though it was not ideal to develop on a system with magic quotes enabled.
Ideally you want to take in form input, raw and when hitting the DB layer it then becomes sanitised.
Secondly, onto the re-writing part of Moodle, are newer versions of moodle removing the automatic escaping of form input? and only escaping via a retreival function such as optional_param() with a parameter to say wether or not to escape the $_POST/$_GET input.
This, in my opinion would be a more elegant solution, giving the developer a more flexible environment and the option to escape the input,leaving the $_POST and $_GET superglobals intact.
Thanks.
Paul.
Thanks for the quick reply.
Yes i realised that the core components would be relying on the magic_quotes or the addslashes_deep() functionality to escape the input.
Therefore i had to keep your escaping mechanism on, even though it was not ideal to develop on a system with magic quotes enabled.
Ideally you want to take in form input, raw and when hitting the DB layer it then becomes sanitised.
Secondly, onto the re-writing part of Moodle, are newer versions of moodle removing the automatic escaping of form input? and only escaping via a retreival function such as optional_param() with a parameter to say wether or not to escape the $_POST/$_GET input.
This, in my opinion would be a more elegant solution, giving the developer a more flexible environment and the option to escape the input,leaving the $_POST and $_GET superglobals intact.
Thanks.
Paul.
Ideally you want to take in form input, raw and when hitting the DB layer it then becomes sanitised.
That is basically how it works in Moodle 2.0. You can download the 2.0 development version now. That part is done.
But the basic message is, in Moodle forget about $_POST/$_GET. Always get input using optional/required_param with the right PARAM_... type; or via a moodle_form (lib/formslib.php). (And don't worry about the ugliness behind the scenes in <= 1.9.)
That is basically how it works in Moodle 2.0. You can download the 2.0 development version now. That part is done.
But the basic message is, in Moodle forget about $_POST/$_GET. Always get input using optional/required_param with the right PARAM_... type; or via a moodle_form (lib/formslib.php). (And don't worry about the ugliness behind the scenes in <= 1.9.)
Thanks for your reply and good to hear the implementation approach for form inputs has been made more elegant and architecturally flexible.
Paul.
Paul.