Reported Bug - Expired Security Token

[carmelchas]

Bug

Based on documentation I have read the feature for CSRF TOKEN verification is not complete. There was a report that stated upgrading to version 13.0.1 fixes the problem in the screenshot below, but it did not. There was also a post that stated setting $dolibarr_nocsrfcheck to ‘1’ in conf/conf.php fixes the problem, but it does not.

Environment

• Version: 13.0.1

Expected and actual behavior

Based on documentation I have read the feature for CSRF TOKEN verification is not complete. There was a report that stated upgrading to version 13.0.1 fixes the problem in the screenshot below, but it did not. There was also a post that stated setting $dolibarr_nocsrfcheck to ‘1’ in conf/conf.php fixes the problem, but it does not.

The following bug-fix provides the list of files and the differences I made to resolve the issue.

In a nutshell the problem is:

A. Multiple files define the constant ‘CSRFCHECK_WITH_TOKEN’ as ‘1’.
B. The main.inc.php asserts CSRF CHECK logic whenever ‘CSRFCHECK_WITH_TOKEN’ is defined and DOES NOT consider the value for the constant.

In a nutshell my temporary solution is:

A. Everywhere ‘CSRFCHECK_WITH_TOKEN’ is defined change the setting to ‘0’.
B. Update the main.inc.php conditions for applying the CSRF logic to additionally require that the value of CSRFCHECK_WITH_TOKEN is not empty. (@see DIFF below)

Steps to reproduce the behavior

Try to deactivate/activate a module and an error occurs. Previous solutions do not work.

Bug-fix - Files

modified: admin/modules.php
modified: core/ajax/constantonoff.php
modified: main.inc.php
modified: user/perms.php

DIFF

diff --git a/htdocs/admin/modules.php b/htdocs/admin/modules.php
index 56b6e6e1f0…8b1a8ea15a 100644
— a/htdocs/admin/modules.php
+++ b/htdocs/admin/modules.php
@@ -29,7 +29,7 @@
*/

if (!defined(‘CSRFCHECK_WITH_TOKEN’)) {

define('CSRFCHECK_WITH_TOKEN', '1'); // Force use of CSRF protection with tokens even for GET
define('CSRFCHECK_WITH_TOKEN', '0'); // Force use of CSRF protection with tokens even for GET
}

require ‘…/main.inc.php’;
diff --git a/htdocs/core/ajax/constantonoff.php b/htdocs/core/ajax/constantonoff.php
index a530bea092…751aca0202 100644
— a/htdocs/core/ajax/constantonoff.php
+++ b/htdocs/core/ajax/constantonoff.php
@@ -26,7 +26,7 @@ if (!defined(‘NOREQUIREHTML’)) define(‘NOREQUIREHTML’, ‘1’);
if (!defined(‘NOREQUIREAJAX’)) define(‘NOREQUIREAJAX’, ‘1’);
if (!defined(‘NOREQUIRESOC’)) define(‘NOREQUIRESOC’, ‘1’);
if (!defined(‘NOREQUIRETRAN’)) define(‘NOREQUIRETRAN’, ‘1’);
-if (!defined(‘CSRFCHECK_WITH_TOKEN’)) define(‘CSRFCHECK_WITH_TOKEN’, ‘1’); // Token is required even in GET mode
+if (!defined(‘CSRFCHECK_WITH_TOKEN’)) define(‘CSRFCHECK_WITH_TOKEN’, ‘0’); // Token is required even in GET mode

require ‘…/…/main.inc.php’;
require_once DOL_DOCUMENT_ROOT.’/core/lib/admin.lib.php’;
diff --git a/htdocs/main.inc.php b/htdocs/main.inc.php
index 78ed3d82bd…7758465420 100644
— a/htdocs/main.inc.php
+++ b/htdocs/main.inc.php
@@ -427,8 +427,9 @@ if (!defined(‘NOTOKENRENEWAL’))
//$dolibarr_nocsrfcheck=1;
// Check token
if ((!defined(‘NOCSRFCHECK’) && empty($dolibarr_nocsrfcheck) && !empty($conf->global->MAIN_SECURITY_CSRF_WITH_TOKEN))

|| defined('CSRFCHECK_WITH_TOKEN')) // Check validity of token, only if option MAIN_SECURITY_CSRF_WITH_TOKEN enabled or if constant CSRFCHECK_WITH_TOKEN is set into page
|| ( defined('CSRFCHECK_WITH_TOKEN') && ! empty(CSRFCHECK_WITH_TOKEN) ) ) // Check validity of token, only if option MAIN_SECURITY_CSRF_WITH_TOKEN enabled or if constant CSRFCHECK_WITH_TOKEN is set into page
{
+
// Check all cases that need a token (all POST actions, all actions and mass actions on pages with CSRFCHECK_WITH_TOKEN set, all sensitive GET actions)
if ($_SERVER[‘REQUEST_METHOD’] == ‘POST’ ||
((GETPOSTISSET(‘action’) || GETPOSTISSET(‘massaction’)) && defined(‘CSRFCHECK_WITH_TOKEN’)) ||
diff --git a/htdocs/user/perms.php b/htdocs/user/perms.php
index 68238b63c2…5fa2b47e38 100644
— a/htdocs/user/perms.php
+++ b/htdocs/user/perms.php
@@ -26,7 +26,7 @@

    \brief          Page to set permission of a user record

*/

-if (!defined(‘CSRFCHECK_WITH_TOKEN’)) define(‘CSRFCHECK_WITH_TOKEN’, ‘1’); // Force use of CSRF protection with tokens even for GET
+if (!defined(‘CSRFCHECK_WITH_TOKEN’)) define(‘CSRFCHECK_WITH_TOKEN’, ‘0’); // Force use of CSRF protection with tokens even for GET

require ‘…/main.inc.php’;
require_once DOL_DOCUMENT_ROOT.’/core/lib/usergroups.lib.php’;

Attached files (Screenshots, screencasts, dolibarr.log, debugging informations…)

[daraelmin]

Duplicate #16096 #16519

[ksar-ksar]

Hello,

With Core modules I don't see any problems on my running instance, so it must be something coming from :

1. An external module
2. A old php file that is not deleted from previous versions
3. Hosting environement

Just removing the protection is a temporary solution but doesn't help us on the resolution.

[eldy]

When you have such a trouble, it means:
You have an external module or a custom development that introduce an Ajax, a CSS page or a javascript file that make a renewal of the token when it should not (in 90% of cases), or you have a page of an external module that send a POST request or a GET for a critical action without providing the token (in 10% of case).
You must try this:

• First go into home - setup - other and check that MAIN_FEATURES_LEVEL is set to 0 or not set at all instead of 1 or 2 (when MAIN_FEATURES_LEVEL is 1 or 2, there is other protection mechanism that are not stable).
• If you still have the problem, you must disable external modules (try to do it one by one to find the bugged module. It may be several external modules).
  If are not able to disable a module from interface, you can try to disable the security check into conf/conf.php by:

• setting $dolibarr_nocsrfcheck to 1 instead of 0 (warning, your instance is no more protected against CSRF attacks)
• setting the constant CSRFCHECK_WITH_TOKEN = 0 into home - setup - other
  If it is not enough and you are still not able to disable external module, you can try by removing directly the directory of the eternal modules stored inside the /custom directory. You can then call this url to clean external modules not correctly removed that still have a bugged files that are loaded.
  /install/repair.php?force_disable_of_modules_not_found=confirmed (you may need to remone the documents/install.lock before)

Don't forget, this is not a bug into Dolibarr but into external files that are not secured or that does implement correctly the security (every ajax, css and js pages of external module must have the define('NOTOKENRENEWAL') in top of their files. Also, any link that have a parameter action=add, action=update, action=delete should also contains the &token=...).
If you modify the code of Dolibarr to bypass the protection or if you keep the dolibarr_nocsrfcheck to 1 or CSRFCHECK_WITH_TOKEN to 0, you are no more protected (at least, no more against CSRF attacks).

With v13.0.2, when the module syslog is enabled, you will also find into the dolibarr.log a line
NEW TOKEN reclaimed by : name of page

So you will be able to see into log what is the page that as the renewal of a token. If this page is an ajax, a css or a js page, you have found the bugged and not secured page (such pages should not claim token renewal).

[dolibit-ut]

Hey, have now with one installation the same problem.

Made an update from 12.0.4 to 13.0.2

now get message 'Security token has expired, so action has been canceled. Please try again.'
and can not edit settings directly in Dolibarr (can't edit other_setup settings or disable modules).

Made now settings like described directly via phpmyadmin or shell - but get always the message
and can not change admin settings in Dolibarr.

[dolibit-ut]

Only disabling modules did not work. Had to remove custom folder to make Dolibarr working again.

[dolibit-ut]

Check now the modules i have used, step by step.

[dolibit-ut]

For me birddy v1.4.2 made trouble.

[BebZ]

Hello Eldy, what is the threat of not being protected by a token ?
Why did you make it mandatory directly on this version, and not optionnal like every other module of Dolibarr to let time to custom developments to adapt ?

[sibeliusg]

I'm on Manjaro Linux. Fresh and clean install of Dolibarr 14.0.5. No extern Modules loaded so far, removed the custom folder. Disabled CSRF-Check, but still have this issue. If anyone solved this issue, please let me know.

[anashaddad]

I'm on Manjaro Linux. Fresh and clean install of Dolibarr 14.0.5. No extern Modules loaded so far, removed the custom folder. Disabled CSRF-Check, but still have this issue. If anyone solved this issue, please let me know.

I am having the same problem and did all the mentioned by Eldy.. but still not able to access as the token expire message always show when I try to loggin

[github-actions]

This issue is stale because it has been open 1 year with no activity. If this is a bug, please comment to confirm it is still present on latest stable version. if this is a feature request, please comment to notify the request is still relevant and not yet covered by latest stable version. This issue may be closed automatically by stale bot in 10 days (you should still be able to re-open it if required).

[sebastienserre]

Hello @anashaddad,
Do you remember how you solved ?
I'm in the same situation with Dolibarr 17.0 ...
Thank you

[carmelchas]

I posted a diff for what I modified in this thread on Mar 11, 2022.

[MrZang101]

The bug is still available.

[kylian-002]

Just did a fresh install of dolibarr 17.0 for the first time. And i cant get past this issue. right after creating my login i am met with the Expired Security token.

[MrZang101]

fixed the issues, is related to permissions on your sftp/ftp where dolibar is installed.

[kylian-002]

fixed the issues, is related to permissions on your sftp/ftp where dolibar is installed.

I do not use sftp/ftp. Also what permissions shut things be set to? i did try /dev/tools/fixperms.sh but it doesnt seem to fix the issue for me