Security information

From Dolibarr ERP CRM Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.


Securite.png Alerts

To receive all official alerts about known security vulnerabilities on Dolibarr project (aggregation of official published CVE, Private Vulnerability Disclosure, project issues) you can look at the section "Security alerts" available on this page https://cti.dolibarr.org, or subscribe to the RSS feed at https://cti.dolibarr.org/index-security.rss (for example with the application Feeder) if you need to receive or read alert in real time on your smartphone.

If you want to also receive security alerts not yet known by the project team, and published in the international CVE database, you can subscribe to a CVE alert service. A good service for example https://opencve.io).

Art.png Security Features

Dolibarr implements several security features to match best practices rules related to security.

This is a list of main security features you can find :


Encryption

  • 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
Values Description

0

No forced redirect

1

Force redirect to https, until SCRIPT_URI start with https into response

2

Force redirect to https, until SERVER["HTTPS"] is 'on' into response

https://mydomain

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. All access to an URL uses the getURLContent() method into core/lib/geturl.lib.php that bring this protection.
  • 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 disabling the Apache option 

AcceptPathInfo Off


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.


Login protection

  • 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 (like 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.


Viruses

  • 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.


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


OpenSourceSSF

Dolibarr conforms to the Best Practices defined by the OpenSourceSSF: https://bestpractices.coreinfrastructure.org/projects/5521

Art.png Report a security vulnerability

To report a vulnerability, see the file: https://github.com/Dolibarr/dolibarr/blob/develop/SECURITY.md

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.

Retrieved from "https://wiki.dolibarr.org/index.php?title=Security_information&oldid=60055"