We are working hard to ensure that myDBR is secure. myDBR is updated regularly, and these updates, in addition to new features, may also contain improvements to security. Make also sure you read any possible security notes in the release notes.
The things listed below ensure that your installation of myDBR is secure.
Environment settings→Authentication / security
Environment settings→Password settings when using myDBR authenticationWhen myDBR is installed, an admin user is created under the name 'dba' with a default password. You should create another admin user with a secure password and disable the original one. Note that this should be done regardless of the authentication method, as local logins are always accessible.
When the server is configured only to accept connections over a secure HTTPS connection, it will protect all information sent. This will include your authentication information, data, and session information.
All myDBR reports are accessible via an URL. To be sure that a URL is generated by a trusted source (myDBR itself or admin wishes access to data required for URL generation), the URL is checked against a hash value that is added to the URL.
The hash value is calculated from the URL parameters and with the URL hash seed, which is installation-specific. To make sure your reports
have a unique hash value, click the Randomize button in "URL hash seed" in
Environment settings→Authentication / security
Enforcing password rules makes passwords harder to guess. See the Wikipedia article about password policy.
Make sure your server is up-to-date. This includes all software components in your server: operating system, server software (web server, PHP) and myDBR itself.
By default, myDBR extends its functionality by offering PHP access to admins. This includes a capability to create myDBR extensions, more customization for extending existing myDBR commands, etc.
With PHP access admin can also access resources inside the server via PHP's filesystem services. If you offer myDBR admin access to the users that should not have access to server files, you can limit the PHP access by adding the following line to user/defaults.php
$mydbr_defaults['admin_restrictions']['can_access_php'] = false;
The setting will prevent admin access to PHP files in 'Server side files'-functionality and prevents admins from using PHP commands to extend existing commands.
Cross-site scripting (XSS) is an attack in which an attacker injects malicious executable scripts into a website. In myDBR context, this would mean that an attacker injects malicious JavaScript code that then admin executes under admin privileges.
myDBR, by default, cleans user input for potentially harmful content, but as myDBR is a programming environment, an admin needs to understand where the data come from. If the reporting environment handles external HTML/JavaScript data or imports data from a third party site, the content may contain malicious code. By default, myDBR encodes the data so that it will be safe, but if you use dbr.html, dbr.html:, or dbr.javascript, make sure you only use them with content that is known to be safe (i.e. own code). For external content, you can use dbr.html.ext, dbr.html.ext:. myDBR then cleans out any potentially malicious code.
myDBR uses Santosh Patnaik's 'htmLawed for cleaning up external HTML when included with dbr.html.ext or dbr.html.ext:. By default, myDBR uses htmLawed 'safe' configuration. You can define your own configurations in user/defaults.php $mydbr_defaults['xss']['htmLawed_options']. For example, to add custom configuration for htmLawed's 'elements', you would use:
$mydbr_defaults['xss']['htmLawed_options']['elements'] = '* -applet -audio -canvas -dialog -embed -iframe -object -script -video -img -a';