Note: Security is not a feature, it's a process!
Manually Set The HSTS Header
If/once DRDB is configured for HTTPS access, it is strongly recommended to MANUALLY set the HTTPS Strict Transport Security (HSTS) header by creating a .htaccess file in the root directory of the project or include the required configuration in the Apache site config. The following code locks use of the site to HTTPS only, no downgrade is possible afterward anymore even when restarting the browser. Therefore, care is advisable!
<IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains" </IfModule>
If you use a .htaccess file in the project folder, already think about how you will do updates in the future and how to preserve your .htaccess file and restore it afte the update!
For details see the OWASP Secure Header Project.
Headers Set By The Code
While the HSTS header has to be configured manually as not all projects might want to use it, the following security headers are already set by the by init.php for each page request. No configuration is necessary:
Cross Site Scripting Protection
Other Security Considerations
In addition, the following security considerations are used in this project to protect against common exploits widely used by rouge actors on the Internet:
HTTP based authentication ensures that only users who know a valid username/password configuration can invoke any servers side code. Without a username/password, the web server itself denies access and hence, no server side project code is executed.
Cross Site Request Forgery Protection (CSRF)
To prevent CSRF via malicious links embedded in other pages, emails, etc., the server code checks HTTP URLs for the presence of a security token before data is written into the database. If the token is missing, an error message is returned to the browser and no data is changed in the database.
SQL Injection Protection
Another frequently used attack vector on the web is SQL injection. To prevent this kind of attack, care has been taken that all SQL queries that require user supplied information are executed as 'prepared statements'.
HTML Input Filtering
Data edited with the GUI editor is sent back in 'html' format to the server. The editor itself filters the HTML data before it is sent back and only allows a few HTML markup options. A malicious user, however, could bypass the editor and directly send malicious HTML data to be inserted into the database in a hand crafted query. As a consequence, the server side also filters user database input before it is written to the database or shown on the screen if protect_against_xss is set to true in config.php, which is the default. When set to true, database input is filtered with the htmlpurifier library.
Host Header Poisoning Protection
In general, the drdb server code only creates links relative to the document root. In other words, the domain name used for addressing the server is not used. In the future, however, it might be necessary to construct links that include the root, i.e the domain name as well. The domain name would then be taken from the HTTP HOST header. As the HOST header is generated by the client, care has to be taken at links are only constructed with valid domain names. Otherwise, an attacker could fake the HOST header to exfiltrate data that is contained in the link (e.g. session tokens, private information, etc.).
To counter this attack vector, config.php contains an array of valid domain names (or IP addresses for testing purposes) for the site. The host header is checked for every http operation and processing is stopped with an error message if the domain name used for the request is not properly configured in config.php.