[Resolved] Security problem in frontend

[Author]

Posts

[jose-manuelR]

Hello

It's about this post: https://toolset.com/forums/topic/subscriber-can-see-this-buttons/

The problem still persists. I say this because I see that the plugin is being updated and this situation has not yet been corrected. Of course the solution given by Nigel works, but I see that they have not yet implemented it

A subscriber user should NOT be able to access these options.

I have performed tests (as a subscriber) and I have been able to access private information of other users. I still think it's a huge security risk.

Thanks!

[Beda]

1. The Fields and Views Button appears in the CRED Form ''only if Allow Media Insert button in Post Content Rich Text Editor is enabled''
2. They appear only for Author and above

This is not a security issue, but a GUI issue.
The Buttons are not related to the "only if Allow Media Insert button in Post Content Rich Text Editor is enabled" and I requested to update this, so it is unhooked from each other.

If you have clear steps, without manipulating the Subscriber User Caps, to access those buttons as a Subscriber, please pass them to me!

[jose-manuelR]

I'm sorry but you're wrong.
I'm not talking about cred forms. I'm talking about text fields like:
Markdown editor
Textarea field
WordPress editor
etc

It is not about Cred forms. And of course, cred forms uses one of these options above

So if a subscriber can add conditions, and with a little knowledge you can see information from other users ... is a security hole

Can you see the image? That user is subscriber and can add conditions

As I said before, the solution given by Nigel works. But I have not seen an official solution yet in any update

[Beda]

Can you exactly elaborate how I can replicate it?

In WordPress, only authors can upload Images in that way, and that is the only way we hook the Buttons.

As soon (with any form of editor be it backend or front end) the user is lower than Author, he will not see those buttons anymore, I tested this extensively.

Please let me know how to replicate it, or send me a Duplicator Snapshot, if it is too cumbersome to outline the steps.
https://toolset.com/faq/provide-supporters-copy-site/

Thanks

[Beda]

Wait a second.

You do not speak about "Fields and Views" or "Access" buttons but about the Views Conditional!

This is replicable (still not as subscriber as those cannot edit a post in any way) but as contributors.

I do not consider this a huge risk, as a Contributor, is a user of trust already.

but please let me know how to replicate the issue with the Subscriber.

[Beda]

I need the steps to replicate this as a Subscriber.

I cannot - on a clean install - replicate this as a Subscriber, as they simply cannot edit or add posts.
If they can on your install it is because the Role is modified.

Or, I miss a huge feature of WordPress - which would allow Subscribers to add or edit posts.

Related to the "what role sees the feature", I cannot agree with this, as it is a backend tool, and everyone in the backend will see many more things.

But, I will pass this concern to the Developers for proper investigation as well as, as soon I have more details on it.

[jose-manuelR]

Hi Sr

I already sent you in the private post the information you need step by step

Thanks

Related to the "what role sees the feature", I cannot agree with this, as it is a backend tool, and everyone in the backend will see many more things.

I agree with you. But do not add conditions. It is dangerous for a subscriber to access information that should be restricted. Anyway, if I give a subscriber permission to add a post ... should not be able to add condition. This is an administrative tool

[Beda]

Anyway, if I give a subscriber permission to add a post ... should not be able to add condition

You customise the Subscriber role.
Hence this is not a Toolset Problem, I am sorry to say this.

This is not a security issue introduced by Toolset, but by manipulating the Subscriber Role in a way that allows them to add and edit certain posts, and that is not done by us.

There is a reason that a Subscriber cannot add posts. He is supposed to be a subscriber, not an editing person.
Every manipulation of any Role has to be done with the correct evaluation first.

You can confirm, that if you have a vanilla WordPress Install Subscribers cannot do anything with any posts.
If a certain Plugin allows Subscribers to add or edit posts, it is up to them to correct this.
WordPress does not suppose a Subscriber to add or edit anything on a Website.

Of course, if you change that, it is under your responsibility.
Giving more rights to a User means also trusting those users.

Additionally, I do not see any security issue.
What personal information can you access in the Conditional GUI?
I am really eager to report this, but I do not see how I could possibly access personal data in the Conditional GUI.
By what I know, none.

And the Views / Access Buttons, as said, they appear only as Author and above.
Conditional is accessible by Contributors and above only.
And this is in line with the job of those roles.

The only problem I see is that Conditional GUI is useless if you do not see "Fields and Views" GUI because to complete complex Conditionals you actually need that "Fields and Views" GUI.

==> Hence, I will request that the conditional and the Fields GUI will both only appear together, or not at all. And that will probably be Author or above, but that is not up to me to decide.

Making them available only for Admins is out of scope.

The Filter that Nigel provided will also enable you to customize the visible part per role, and that is how WordPress works:
Make choices, not options.

This means, we will not add a lot of Settings options where a user can enable or disable those buttons, but we provide a Filter that allows you to unhook it on a user Basis.

But, I will also ask to Document that/those hook(s), as it's an API hook and it is an important one.

I hope I did not miss anything. Please feel free to correct me if so.

[jose-manuelR]

You are focusing all the information in the wrong way.

The plugin that I put was just an example and has more than 200,000 active users worldwide, But there are many plugins that allow a given role to add information using the visual wordpress editor...subscriber or some rol CREATE BY THE OWN ADMINISTRATOR.
So there are more than 3 million users (and I'm being fair because they obviously are more) who are not administrators who can add conditions and put information that should ONLY put administrators.

Now, as administrator, I create a condition in which I determine that if the user logged in is an administrator or author, they can list all the users of the site, for example. Why a role that I have created that in theory can only add information and is not admin or author can see all the users of the site?
And this is just an example of what can be done and I am not to give you a class. My knowledge is different from yours (I am convinced that your knowledge is greater than mine in programming issues). But your knowledge is also different from that of my workers

And that is your mistake. To think that it is not possible to access private information just because you can not
It is a mistake to imply that you should not create roles that allow posting. AND I DO NOT HAVE SUBSCRIBERS. I'm talking about other roles created just for that purpose.
I can create new taxonomies and post types (nothing to do with the post standars) and the new role that I created, which of course is NOT an administrator, can add conditions. I still think it's a mistake

Why? Why should a simple role be able to add pre-designed conditions?
What is the need for this option to be visible to non-administrators?. Author, contributor?...maybe. But why others?

Other plugin programmers also add options to the visual editor of wordpress, but this programmers understand that they should only see and access to the administrators. Why not do it with toolset?

If you represent the toolset staff I will tell you one thing: Of course you can do what you want and not keep in mind what I say. We have 4 license in the company (we have 4 because they are separate departments and we do not want to mix things) and we are really happy. Why do I tell you all this? Because in September we will buy 2 more for some client. We have always thought that toolset has good tools and we continue to think that toolset does it well. But when customers ask us why another is NOT an administrator can add conditions ... seriously?
If the staff disagrees with the things I say is not a problem for us. But that subtract importance to the security ... generates great consternation and preoccupation in us. Security is not just programming with responsibility. There are other things that are being neglected if the staff sees things like you

Thank you for your attention. You do not need to respond to this post. Please, we give this conversation to finished

[Beda]

Ok, we seem to have a different understanding of what a Subscriber Role is, what contributor is and what an Admin is, and what they do and what not

It is not WordPress behaviour to let a Subscriber edit or add a post.
Contributors can, and as stated, I also filed requests to adjust certain discrepancies.

I still do not know, how a certain user could exploit security with this.

Once again, adding conditions is not something that is restricted to Admins. This is clear, because and Author and a Contributor can edit posts and should be able to add HTML conditional, that is not disclosing any form of Personal Information.
Subscribers can not do that unless you modify the Subscriber role, which is something each Developer has to do explicitly on the website

Now, as administrator, I create a condition in which I determine that if the logged in user is an administrator or author, they can list all the users of the site, for example. Why a role that I have created that in theory SOLO can only add information and is not admin or author can see all the users of the site?

Well, If that user, can edit posts, he can also edit the conditional even if the GUI is not present
Once again, it is each admin's own risk, how much power is given to lower roles.
Seeing that GUI or not does not avoid you to manipulate the ShortCode it generates in a Post Body.

Why? Why should a simple role be able to add pre-designed conditions?
What is the need for this option to be visible to non-administrators?. Author, contributor?...maybe. But why others?

As said, and shown, Subscribers cannot do it.
Only if you give very special rights to a Subscriber, that make the Subscriber basically no more subscriber, (or any other role to be), then that is expected.

But since I am not an expert, I forwarded this to our security team which will reply here soon.

I am sure they will find a solution for you.

[Juan]

Hi there, Jose Manuel

This is Juan, Toolset team leader. Thanks for your feedback.

For the next time, and for the record, and given that this is the second ticket related to this same subject, I would like to remind everyone that we have a dedicated mechanism to report security issues, or security concerns:
https://toolset.com/report-security-vulnerability-issues/

Now, on topic.

The Fields and Views (here Campos y Vistas), Access and Conditional output buttons are helpers to generate content. As a rule of thumb, and because of that, anyone with the ability to generate content can see them (even though the two first buttons are only available over editors with Media management buttons).

The Fields and Views button lets you add extra information about this, or other, posts. Also, about the site, or add a View or Content Template. It lets you also display information about the current, or other, user, but hot sensitive or private information, bu the one available publicly for that user.

The Access button lets you create chunks of content that are available to, or hidden from, specific user roles.

The Conditional output field lets you create chunks of content that are visible or not depending on a series of conditions.

None of those mechanisms involve any kind of security issue, since:
- users can not upload custom code, or execute it.
- users can not display restricted or private information, at least in the WordPress sense of restricted.

Now, I can think of some scenarios where someone might think otherwise. Imagine you give subscribers the right to publish posts. Or imagine that you want to restrict what contributors, o even authors, can do. You want them to be able to upload images and audio, but not to be able to display the nickname of another user. That is fair, and a good request, but that is not a security issue, much less a security hole. That is a request to have granular control of who sees what, in the general state that users that can create content do get helpers to enhance that content.

I am sorry to disagree, but conditions are not administrative tools. Conditions are helpers to shape content, and whoever can add content should be able to enhance it with the available tools, unless the site owner decides and acts in a different direction.

In this light, the solution already provided is still valid (to a point, as explained below). As a specific request that deviates from the natural behavior of things, having a filter that modifies the way it works is a valid workaround. Of course, someone might prefer to have a GUI with a way to set such options, and restrict the usage of such buttons to admins, or editors, or authors and above. Those all are valid feature requests.

But again, we are not facing, as far as I can see, a security hole. An opinable mistake? A feature that someone wants thieir users to not see? Yes. But a security hole?

You mention that you have been able to access private information of other users. I would love to see an example of this, and in case we do have a real security hole, we will act inmediately to solve it. We can discuss this information here, I can set anothe rprivate answer for you if you want me to, or you can use the contact form I linked above.

Again, I am sorry to disagree, but listing the users of a site is not a security hole, as users are, in general, public information of that site. To get the username of every single registered user in your site you just need to know a specific URL (I can share it with you if you want), and go testing user IDs from 1 to whatever number you decide. The rewrite rules of WordPress will inmediately return the username for all IDs matching an existing user.

A second aspect of this all is the focus on the GUI. Yes, we show buttons that let you enhance your content. But you can achieve the same result without this GUI, just writing your shortcodes manually. Any user with a role capable to publish or edit a post can add anything provided by those three mentioned buttons, just checking our documentation. Icluding dispalying the nickname for anothr user, of course.

So if any of those shortcodes displays sensitive information in a wrong way, what we face here is beyond the GUI and a pure, real security thread. But I still have not seen any proof, example or data related to that, beyond the petition to restrict those buttons to be used by only admins.

We should get to real examples on how this can affect the security of a site. Otherwise, there is very little that we can do. After reading this long discussion I still do not see any clean path of action at all that reaches further than that someone things should only be available for admins.

Hope this helps.

Juan.

[Beda]

Hello Jose-Manuel, I wanted to check in if you have received the above reply of Juan, the Toolset Team Leader.

Thank you 🙂