Cross-site Scripting (XSS) - Stored in mautic/mautic
Reported on
Jan 12th 2022
Description
When installing Mautic (both via UI or CLI) the first and last name of the admin account are not sanitised before being stored in the database.
This results in a possible stored XSS possibility, as those fields are displayed and re-used without any sanitisation.
During install the raw user input is stored without sanitisation, see codebase
Mautic uses that data to determine the name of a user in the User::getName() method, see codebase
That method is used to:
- display the name in the the user's menu, see codebase
- display the name on the profile page of that user, see codebase
- persistently store the name as
createdByUservalue on every entity that uses theFormEntityas base class ( e.g. segment, contact, form, campaign, ... ), see codebase
Because that name is stored on every entity, following issues occurs as side effect:
- The
createdByUservalue is displayed without any sanitisation in a generic helper template, see codebase - That template is used on the detail page of entities, e.g. on a campaign
Proof of Concept
- Install a vanilla Mautic 3 or 4 via UI or CLI, and use
<script>alert('XSS')</script>firstnameas admin first name in the install process. - login to Mautic, and you will get the XSS alert
- create an entity in Mautic (a Segment, Contact, Form, ...)
- change your first name to remove the XSS part
- go to your profile, and the XSS alert is not present anymore
- go to the detail page of the entity you just created, and the XSS is still there
Impact
While this may look like a not so impactful issue (why would an admin add stored XSS to his own Mautic instance?), following scenario is possible:
- someone does the initial installation of Mautic for you, without any direct access to database or server.
- he and adds an XSS payload to his first or last name during install
- he creates content that will be generally used by other users in the Mautic installation, e.g general segments, forms, ...
- he changes the first and last name again so everything looks normal
- you reset the password and email address of that account to prevent access from the other party.
- every time you visit an entity the initial admin created, the XSS fires as the initial admin's name with XSS payload is still displayed
Occurrences
InstallService.php L464-L465
When installing Mautic (both via UI or CLI) the first- and lastname of the admin account are not sanitised before being stored in the database.
Thanks for reporting the issue! I'll pass this along to the security team for them to review.
@mollux - I understand that you are potentially looking to submit another XSS report via our platform to the mautic maintainers.
We do encourage vulnerabilities of the same weakness to be submitted together, but just so we can form a better opinion, can you help us understand your situation and new report?
Hi, the XSS in this report is in the installer part, and requires a specific ownership over the setup phase of mautic.
The new vulnerabilities are also stored XSS, but are present for any logged in user with mail rights (which is almost every logged in user), and is also publicly accessible by anonymous users. So even though they are the same type of vuln, they have a very different vector and impact.
@mollux - apologies for the delay in my response.
For now, I'd recommend waiting for this report to be in/validated, and then disclosing the new report, or including it in this report.
I understand that they have a different vector and impact, and so submitting in a new report, once this has been addressed is probably the best course of action for now.
However, I have shared this with the team, and we will discuss better mechanisms to make this easier in the future.
Let me know if you have any further questions or need anymore support - my door is open!
Thanks for the issue report, confirmed in 4.x and as you suggest it should probably also happen in the 3.x branch as well so we'll need to back-port the fix.
This is being tracked by the security team in MST-28 for reference.
Are you able to make a PR to address this? If so we will create a private fork against the security advisory to work on - please do not work on this in a personal fork.
Hi, I already added the patch to this issue, I just retried it, but it disappears here. see https://github.com/mollux/mautic/tree/installer
Adding the link to the advisory just for consistency: https://github.com/mautic/mautic/security/advisories/GHSA-jrwm-pr9x-cgq3 - this is where we'll work on the fix.