Security hole OR my mistakes in settings?

Hey you!
I ran into new problem.
I have 2 user: admin (with sudo) and user with limit rights (without sudo).
Both users behave correctly then I use manager panel directly.
For example, user with limit rights does not see the system settings (because I didn't give the rights for it).

So, essence of the problem:
###
I logged as user with limit rights, created resource (content = snippet), wrote the snippet with the following text:

$sql = "update modx_system_settings set value='New Site Name' where key='site_name'";
$stmt = $modx->prepare($sql);
$stmt->execute();

Then I opened the resource in my browser and refreshed the manager panel. The site name has become "New Site Name".
###
And I can change not only system settings, I can change every table in my db (access settings, etc.).

Why it happends? How can I fix this?

If you give a user the right to create a snippet or plugin, there's no easy way to control what the snippet or plugin can do.

You can update the Policy used for the user's Context Access ACL entry and uncheck any permissions with the word snippet or plugin in them. Flush permissions and log out all users before testing your changes. [ed. note: BobRay last edited this post 6 years, 1 month ago.]

The problem is that my user with limit rights is a developer. He must create snippet to do his work.
I can't deprive him of this opportunity.

If you can trust him to develop, maybe you can trust him not to mess with the System Settings?

If his snippet use the MODX processors with $modx->runProcessor() ), his permissions will stop forbidden processors from running.

If he uses xPDO (as he should), the permissions will also apply.

In your code above, you've executed your low-level query directly, which bypasses xPDO. There's no reasonable way to control what PHP code he writes, so if he knows how to do direct DB queries in MODX with your method or PDO, and wants to cause trouble, he can do whatever he wants with the database.

Try this code when logged in as your developer. I believe the permissions will block it:

Quote from: BobRay at Mar 17, 2018, 04:50 AM

In your code above, you've executed your low-level query directly, which bypasses xPDO. There's no reasonable way to control what PHP code he writes, so if he knows how to do direct DB queries in MODX with your method or PDO, and wants to cause trouble, he can do whatever he wants with the database.

Very interesting.
So as I understand I have to tell a developer: "Hey! You can't use PDO (low-level query directly), you must use xPDO, because PDO queries may crush modx system."

Developer has to tell me: "Ok. No problem, but why you don't deactivate PDO queries for me, if I must accidentally crush something in your system?".

I have to tell him: "You are right! And I don't understand for what need Access Setting. Every user which have access to edit and save snippet can assign yourself as administrator with sudo rights! It's bull**it."

Does anyone know how to deactivate PDO request for the not-sudo user?

Every user which have access to edit and save snippet can assign yourself as administrator with sudo rights! It's bull**it."

Please calm down. I'm just doing my best to answer your questions.

If you were able to block PDO requests for a specific user, MODX would not work at all for that user. MODX runs on xPDO and xPDO is a wrapper for PDO.

I'm not aware of any content management system that will allow a user to write PHP code to modify the database but that will restrict them from making specific modifications.

If you can find one, it sounds like it might be a better fit for you than MODX, since it you are apparently worried that your developer is either untrustworthy and/or incompetent. When you take a car in for service, you have to trust the mechanic not to damage something, copy your car key, or steal your fuel. Think of your site like a car and only hire developers you trust.

A few things to think about: 1) creating a new context (dev.domain.com) and limit the developer there and 2) forcing the developer to a single user/resource group.

Backup the database and site daily - regardless.

Quote from: wshawn at Mar 19, 2018, 11:07 PM

A few things to think about: 1) creating a new context (dev.domain.com) and limit the developer there and 2) forcing the developer to a single user/resource group.
Backup the database and site daily - regardless.

W. Shawn Wilkerson, could you explain a little more?