Last update: 2021-07-5
Some SQL injections and CSRF vulnerabilities have been reported. They are a small risk as they are in pages that need to be logged to be used. Fix is available into 13.0.2.
Note: You can download from GitHub the intermediate versions (not yet released maintenance package) from version 13
Dolibarr implements several security features. Among them :
- User passwords are encrypted in database [*7] [*8].
- Database technical password can be obfuscated into the Dolibarr configuration file (conf.php) [*8].
- Possibility to force HTTPS [*9].
//conf/conf.php file //example of $dolibarr_main_force_https configuration $dolibarr_main_force_https = '1';//to force https
No forced redirect
Force redirect to https, until SCRIPT_URI start with https into response
Force redirect to https, until SERVER["HTTPS"] is 'on' into response
Force redirect to the https domain name mydomain (recommended method)
Hacks and cracks
- Works with register_globals on or off (off highly recommended) [*2].
- Works with PHP safe_mode on or off (on recommended) [*3].
- Production option to disable any technical information leakage like debug, error stacktrace, version informations (See configuration file) [*6].
- Protection against SQL injection. Protected by an Internal WAF, and unit test to check database good practice for escapement. [*2].
- Protection against XSS injection (Cross Site Scripting). Protected by an internal WAF and web page headers. [*1].
- Protection against CSRF (Cross Site Request Forgery). Protected by an internal WAF and a token system. [*5].
Note that it is also recommended to protect your web server by disabled Apache option
Pages and files access
- Pages and contents are protected by centralized entry code to check permissions (granted on groups or users for each functional module) [*4] [*10].
- Files saved by Dolibarr are stored in a different root directory than web application (so they can't be downloaded without passing by the Dolibarr wrapper) [*3] [*10]. Note: You must check that you did not choose the "document" directory (for upload files) to be in same directory neither in a sub-directory than the "htdocs" directory. You web virtual host must point to the htdocs directory only. So any uploaded file (and store into the document directory can be called by forging a simple URL.
- Dolibarr directories content can't be accessed even if Apache option Indexes has been forgotten to on (should not) [*3].
- Delay anti brute force cracking on login page [*7]. Currently this delay is fixed (May be exponential with tries in a future version).
- Option for graphical code (CAPTCHA) against robots on login page [*7].
- Restrict access to backoffice for some IP only [*7].
- No passwords in logs, even in technical logs [*7].
- Internal logger to save permanently all Dolibarr events about user's administration and successful or failed logins or administration events (user or group or permission changes).
- Can output a log record into a log file (module Debug Log must be enabled with at least level 5-LOG_NOTICE on production server, higher on development server) after success or failed login attempt so you can add a fail2ban rule to lock brute force cracking. You can check record with syntax :
"YYYY-MM-DD HH:MM:SS (ERROR|NOTICE|INFO|DEBUG) IP functions_dolibarr::check_user_password_.* Authentication KO"
- Possibility to run an external anti-virus on every uploaded files [*3].
Report a security vulnerability
- You can submit an email at email@example.com
- Or (better) you can use the security feature of GitHub on https://github.com/Dolibarr/dolibarr/security
In most cases, security reports are processed in few days only.
(*X) This solution is part of protection used to solve vulnerabilities classified by the OWASP Top Ten at range number X.