Thank you. I almost figured out the issue. But the question remains. Can an administrator sign the code? Yes!!! Why can’t I whitelist {echo} by creating a signature? To eliminate the possibility of changes in the database, a sufficiently white list must also be signed with a salt and a hash. I don’t see any particular difficulties here.
I believe that creating a white list must be available to the administrator. And only then, if the developer wishes, he can add his own rules to function.php. Even if it is difficult to track who is in charge (white list in settings or white list in function.php), then you can automatically disable this setting in Bricks if there is a function exist in function.php “white_list” . Determining whether a function exists or not doesn’t seem to be a problem either.
If you create what I wrote above, then you will be able to please not only ordinary users who only need date() without effort and pain, but also developers who will be able to create their own rules.
Thanks for the explanation, so it was generally an insecure REST endpoint that caused all this?
So then, if the REST/Ajax calls are now secured, why are we still talking about hackers still executing functions? Is the REST fixed or isn’t it? Or are they hacking through some additional insecure endpoint?
This is so weird to me because we’re talking about the dynamic and live display of the echo function within the context of my edit screen. The hacker would require a way of hijacking some user’s existing session? Is it a session hijack then? Man-in-the-middle? Cross-site forgery (CSRF)? XSS?
I’m just surprised, in the age of one-page apps and proliferation of ajax/rest calls, which probably ALL WordPress plugins do at some level, and WP itself, none of these other tools seem worried about their endpoints to this degree, or executing arbitrary code. If the endpoint is secure and properly authenticates and validates the user, then what are we still worried about?
Without the whitelist feature at all, how less secure is it really? We’re making it sound like any ol’ hacker or script kiddy can jump right in and execute code. I imagine it’s much harder than that!
Take this with a grant of sail… I’m not sure about the following:
When you use “Filter” elements or Ajax Search features the frontend do a REST/AJAX request to refresh what is rendered.
These request should execute {echo} if the template to be refreshed includes {echo} calls.
You cannot put these AJAX calls behind a login, otherwise you cannot have a page with Ajax Filter or Search functionality that is usable from unauthenticated user.
The question would be, how would an attacker change the echo function that is being called in the first place? It’s not like raw Bricks dynamic tags and php code are being put in the frontend in plain text where a person could tweak it before sending back to execute.
Unless I got it wrong, the server is processing the response and the dynamic tag is part of the page/template source code, not something a frontend user gets to see and edit before it gets processed.
For example, in my page global footer is a dynamic tag for getting the year. But the unauthenticated user only sees “2024”, they don’t see anything about the actual tag, they can’t edit it before it gets executed by mucking around in JS and page headers. It’s part of the server response, entirely processed in the backend. Why would an anonymous end user have access to adjust the function being called by the dynamic tag?
I will share your suggestion with the team, but I personally think this would be more cumbersome than the 2 proposed solutions here: WIP: Better solution for echo function name filter - #10 by thomas. Singing the whitelist would require you to review and re-sign it each time you add a new echo tag. Whereas the 2 proposed solutions provide more flexibility (e.g. allow all functions during development and then set stricter rules when pushing to prod).
I’m not against the two proposed options, I just want to offer a third one that will not force users to learn PHP and implementation methods.
If there is a concern that the user will click “sign the code” every time, then you can add a “development mode” in which the rules will be ignored.
But even here the fears are in vain. If the user starts clicking “sign the code” every time, then he needs a lot more than just date() , which means he is prepared and knows what function.php is and how to work with it.
It’s just that many people here learn about CSS for the first time, and the Bricks team wants to immediately plunge the user headlong into the jungle of PHP development.
︎