Hello, I just realised that is possible to inject code into the default fields like pagetitle, etc…
I think that is a massive security issue.
Anyone that can tell me how to avoid that?
for example:
"><img src="#" onerror="alert(1)" />
into pagetitle, will trigger an alert.
Thanks!
just don’t let people, who you do not trust, into the manager?
As soon, as they have access to the manager and permissions to save chunks, snippets, resources, templates, files… they could allways inject code.
If you want to let them save only resources without any html-tags and nothing else, the first step would be to give them only permission to save resources, but no chunks, snippets, plugins and anything else.
then you would need a plugin at OnDocFormSave or OnBeforeDocFormSave, which would strip all tags, if they are not allowed to put tags into resource-fields.
This is a client’s website, where many people needs access to create forms using formalicious and checo other things, so I think create a front end is not an option.
The users only can see the necessary into the manager because the restrictions they have, but with this problem anyone with the right knowledge can inject code and will be able to access to the database or anywhere.
I think this is a big problem because it’s not possible to control what the web editors can do.
Am I wrong?
If those xss issues happen in the manager, that would be considered a (low level) vulnerability. Low level because as Bruno says, the manager is considered a trusted environment as there are a lot of ways for people to wreck havoc with that sort of access. Those could be reported on GitHub or through security@modx.com. Make sure you’re running the latest version and not a custom manager theme tho as I seem to recall pagetitle related issues being fixed.
If the issues happen in the frontend, you can use the htmlent output modifier to escape the fields, e.g. [[*pagetitle:htmlent]]
Using the last version on a normal ModX installation, you can test it on any page just put the code into the pagetitle field.
I think a low level vulnerability at the en is a vulnerability. Sometimes you can not control who is accessing the manager if the site is a big site with many users.
That is why the restrictions are applied for every level of user, but in this case even the lowest lever of access can inject code into the manager via generic input fields.
I’ll report it, thanks Mark!
then you would need to restrict the input of html anywhere else, like the content-field, in chunks, in templates etc. and the CMS would be useless. Not sure, how you want not to allow to add html-tags and allow to create forms at the same time.
For backend security it’s not about preventing html from being entered in a field - it’s about preventing that html from executing.
A restricted user in this case has not access to Chunks, Stnippets, tempates, some resource pages, context are restricted and most of the top menu like Extras, Manage, etc…
They only can create delete pages inside an specific context, create forms in formalicios and check the forms into formIt.
Why an user with all this restrictions can inject and execute code from an input field into the manager?
I think the proper way is that the user can put any type of code into the fields like pagetitle but for security that code must be handled as string text and not executed inside the manager when the resource is open that is what is happening right now.
I can’t reproduce this. Nothing is getting executed inside the manager from the pagetitle field in my tests. Are you using the latest release?
Hello mate.
Just put this into the pagetitle:
"><img src="#" onerror="alert(1)" />
save the resource, close it and open it again, you will see the js alert.
Yes, last release!
Thanks!
Hi, I can see this alert too in MODX 2.7.3 (with VersionX).
In another installation I’ve 2.7.0, but there is no alert … and … no VersionX …
After removing the injection string from the title in 2.7.3, the alert is still coming up.
I think it’s because I am using VersionX plug in, which shows the title in the overview …
Exactly the same problem here with versionX.
Once the code is there and it execute itself every time a page is open, versionX make it worse because there is not way to delete the saved version and the code keep executing it self every time a page is opened, at the end the solution was delete the resource. Crazy!
I still thinking it is a vulnerability ModX support called a feature, jmmm…
Here their answer:
“As far as I can tell, this is not reflected XSS because it is not executing the code being inserted in the manager. I would suggest continuing the conversation in the forums if you are trying to make it so someone cannot enter this kind of data to be presented on the front-end of the site. That is beyond the scope of a security vulnerability, however, since users who have access to edit resources can put whatever valid markup they want into the manager. This is a feature, not a bug.”
Can you confirm the popup does not appear if versionx is not installed/disabled? If so, that means it’s an issue in versionx and not core.
Since I was unable to reproduce the problem in the core, I was simply telling you if you were trying to prevent the code being entered in the manager from being presented on the website, THAT was not a bug. Since others are able to reproduce the reflected XSS bug with VersionX installed, as Mark suggested, it is a bug with VersionX, and not the core of MODX. For future reference, the security address is for reporting security vulnerabilities you have confirmed exist in the core of MODX, and not for general support. Support is precisely the purpose of these forums where I directed you back to.
It’s not necessary to delete the resource, it can be fixed in the table modx_versionx_resource of the database. This in turn speaks for having the xss in the versionX plugin.
Perhaps the problem can be fixed in your case when parsing (and correcting) the input with an own plugin using a system event (p.e. OnBeforeDocFormSave).
I’ve released VersionX 2.3.2 which fixes these XSS issues.
(Some other core XSS issues that I identified in the progress, requiring admin/template edit permissions, are now reported in the MODX repo.)