Security Principles
Variable Checking
Where possible scripts should as quickly as possible check for any needed variables and exit if these are missing. The advantage of exiting if they are missing is to minimise PHP warnings and fatal errors.
New code must use one of these methods to to access all variables passed to a page.
The param class contains 4 methods that can be used to check and clean variables passed to a page:
param::clean()
param::clean($value, $type)
Parameter | Type | Explanation |
---|---|---|
$value | mixed | The value that should be cleaned |
$type | int | The type that $value should be cleaned as. It should be passed as one of the param class constants, i.e. param::FLOAT |
The cleaned value will be returned, or null if it does not match the type passed.
param::clean_array()
param::clean_array($value, $type, $required)
Parameter | Type | Explanation |
---|---|---|
$value | array | The array that should be cleaned |
$type | int | The type that $value should be cleaned as. It should be passed as one of the param class constants, i.e. param::FLOAT |
$required | boolean | Default: false. If true and a parameter in the array is not of the required type an exception will be thrown. |
Returns an array containing only values of the appropriate type, if required is true a MissingParameter exception will be thrown if any value of the array is not of the required type.
param::required()
param::required($name, $type, $from)
Parameter | Type | Explanation |
---|---|---|
$name | string | The name of the parameter to be retrieved |
$type | int | The type that $value should be cleaned as. It should be passed as one of the param class constants, i.e. param::FLOAT |
$from | string | Default: param::FETCH_REQUEST. Should be one of: param::FETCH_GET, param::FETCH_POST or param::FETCH_REQUEST |
Returns the value of the parameter if it is set, throws a MissingParameter exception if the value is either not set, or invalid for the type.
param::optional()
param::optional($name, $default, $type, $from)
Parameter | Type | Explanation |
---|---|---|
$name | string | The name of the parameter to be retrieved |
$default | mixed | The value that should be returned if the parameter is not set, or not of the correct type. |
$type | int | The type that $value should be cleaned as. It should be passed as one of the param class constants, i.e. param::FLOAT |
$from | string | Default: param::FETCH_REQUEST. Should be one of: param::FETCH_GET, param::FETCH_POST or param::FETCH_REQUEST |
Returns a value
check_var()
check_var($name, $method, $mandatory, $headers, $return_var, $type)
Parameter | Type | Explanation |
---|---|---|
$name | string | The name of the parameter to be retrieved |
$method | string|array | Should be one of: param::FETCH_GET, param::FETCH_POST, param::FETCH_REQUEST, or an array |
$mandatory | boolean | If true then exit if the variable does not exist |
$headers | boolean | If true then output HTML header code on a failure |
$return_var | boolean | If true return the value of the tested variable back |
$type | int | Default: param::RAW. The type that $value should be cleaned as. It should be passed as one of the param class constants. (Since Rogo 6.3.0) |
To check for variables include:
require_once '../include/errors.inc';
To check for a specific variable use:
$labID = check_var('labID', 'POST', true, false, true);
This will look for a variable ('labID') that was submitted using POST and if exists will assign to the local variable `$labID`. If $_POST'labID'] does not exist then a warning is set to the user interface and the script will exit.
Denning Access
For security reasons the warning 'Page not Found' is used in situations where a) the current user is not authorised to see the current page, and b) what is being requested is not found in the database (e.g. paperID=9999999999). This is a security principle so that users do not sniff around to see what data exists and what does not.
Access denied failures are recorded by using the record_access_denied()
function which will write to denied_log table. This is useful for SysAdmin users to pick up any patterns of users 'attacking' the system.
Paper Identification
Staff screens can use the internal paper number (e.g. PaperID) and it is OK to pass this around as a GET parameter on URLs. However, any student accessible screen should use 'crypt_name' so that IDs are not guessable.
Database
Rogo has a number of MySQL users with various permissions. After a successful authentication Rogo will switch to an appropriate MySQL user based on the role of the user held within Rogo. So, for example, a member of staff user will use a staff database role and a student a student role. Within the database the permissions that a staff user has on the individual MySQL tables is more extensive than a student. The advantage of this architecture is that a rouge script that tries to do something is should not (i.e. student deleting a user record) will not have the correct database permissions to do so.