Actions

Developer Area/Retrieving user input: Difference between revisions

From Mahara Wiki

< Developer Area
No edit summary
No edit summary
Line 1: Line 1:
As in many things, Mahara is based on Moodle in its API for fetching user input. (Also, this page is based on http://docs.moodle.org/dev/Security#Don.27t_trust_any_input_from_users )
As in many things, Mahara is based on Moodle in its API for fetching user input. (Also, this page is based on http://docs.moodle.org/dev/Security#Don.27t_trust_any_input_from_users ).
 
=== Don't trust any input from users ===
 
This is a basic tenet of web security. '''Do not''' use raw values from $_GET, $_POST, $_REQUEST, $_COOKIE, or any other source of input from outside of Mahara itself. All inputs from any source should be checked for valid values, whitelisted where possible, or blacklisted if whitelisting isn't possible.
 
Fortunately, Mahara provides several ways to do this scrubbing, whitelisting, and blacklisting for you.


=== Forms ===
=== Forms ===

Revision as of 18:34, 16 Ocak 2014

As in many things, Mahara is based on Moodle in its API for fetching user input. (Also, this page is based on http://docs.moodle.org/dev/Security#Don.27t_trust_any_input_from_users ).

Don't trust any input from users

This is a basic tenet of web security. Do not use raw values from $_GET, $_POST, $_REQUEST, $_COOKIE, or any other source of input from outside of Mahara itself. All inputs from any source should be checked for valid values, whitelisted where possible, or blacklisted if whitelisting isn't possible.

Fortunately, Mahara provides several ways to do this scrubbing, whitelisting, and blacklisting for you.

Forms

  • Use Pieforms when you need a form
    • Use an appropriate 'type' value and validation methods for each field
    • Pieforms includes a sesskey value, to help prevent click-on-this-URL attacks
      • Though unlike Moodle, the sesskey is not regenerated on each pageload

Query Parameters

  • For query parameters:
    • Do not access $_GET, $_POST, or $_REQUEST directly
    • Instead, use the param_* methods in lib/web.php, in order to whitelist values for the appropriate data type
      • param_alpha
      • param_alphanum
      • param_boolean
      • param_integer
      • param_integer_list
      • param_signed_integer
      • param_variable
        • This one doesn't actually do any whitelisting; it just allows you to be consistent in API usage
    • Note that the param_* functions can take two arguments. The first is the name of the parameter, and the second is the default value to be used if the query param isn't present. If you supply no default, it will throw an exception if the param isn't present.

Comparison with Moodle 2

  • Optional integer query param
    • Moodle-style: $foo = optional_param('foo', PARAM_INT, 0);
    • Mahara-style: $foo = param_integer('foo', 0);
  • Required integer query param
    • Moodle-style: $foo = required_param('foo', PARAM_INT);
    • Mahara-style: $foo = param_integer('foo');

Other user inputs

Inputs from other sources (like $_COOKIE, RSS feeds, etc) should also be whitelisted and validated as appropriate. The param_* functions can't be used for this purpose because they don't separate validation and value fetching. However, there are some other cleaning & validation functions in htdocs/lib/web.php, so you can check there for an appropriate function. If you don't find anything appropriate, the PHP built-in function input_var() will usually work: http://www.php.net/manual/en/function.filter-var.php