Last update: 2023-03-18
A vulnerability allowing a user to get the list of the contacts (retreiving the lastname, firstname and the id of contact in database) has been discovered. Fix is available into 17.0.1 and higher versions.
Note: You can also download from GitHub the intermediate versions (not yet released maintenance package) for all branches/version (https://github.com/Dolibarr/dolibarr/)
Dolibarr implements several security features to match best practices rules related to security.
This is a list of main security features you can find :
- Passwords or security keys data are encrypted in database [*7] [*8].
- The 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 mode 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 SSRF.
- 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 (and this directoy can/should be in read only mode). So any uploaded file (stored into the document directory) can't be download without using the wrapper page.
- 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"
A list of fail2ban rules to add to your server is provided on chapter DOS and Brute force rate Mitigation later.
- Possibility to run an external anti-virus on every uploaded files [*3].
Security Information Center
- From version 14, you will find into menu Home - Admin tools - Security, a security information center that report you all recommandations done and to do related to your installation.
A CTI for security
A continuous integration platform run Security unit tests and static code analysis on each modification of code.
A footprint for each version
Our release process bring each version with a footprint file (also available online) to validate all files of your local installation.
Note: Dolibarr conforms to the Best Practices defined by the OpenSourceSSF: https://bestpractices.coreinfrastructure.org/projects/5521
DOS and Brute force rate Mitigation
The project provide examples of some fail2ban rules to block brute force attempts or abusive access on login page, password forgotten page and on any public pages. See https://github.com/Dolibarr/dolibarr/tree/develop/dev/setup/fail2ban
Report a security vulnerability
- To report a vulnerability, see the file: https://github.com/Dolibarr/dolibarr/blob/develop/SECURITY.md
- If you are allowed, you can also 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.