Description:
I try to find a solution to add the “sentence” arg to the Query block as posted here:
During my attempts to understand what the query block is doing (to place a hook) I came across a possible vulnerability.
In a generated javascript file called “Filter-2ef4007b.js” there is a variable t that consist of the query object which has a member called stringArgs which shows all query args in plain text.
That means, whatever I enter in the Query Builder as static values will show up on the frontend and be accessible pubicly for anybody.
Here is another example with the Author filter:
In the Query block “Frontend Rendering” is enabled. I have a Filter block with a search input field connected to the Search filter in the query. I am not logged in in the backend.
I don’t now if this behaviour is actually a bug, and how dangerous it may be. But one should at least be aware that static values entered in the Query block fields is accessible from the frontend by the visitor and is not secret!
This does mean that your query parameters will be available publicly, as otherwise the request would not be properly processed (for initial and consequent filtering).
While developing the Frontend Rendering functionality, we made sure to not process data sensitive parameters that could lead to unwanted post retrieval.
Please correct me if I’m wrong, but the post_password parameter is not currently processed when Frontend Rendering is enabled.
I appreciate you would like to keep the initial - non-necessary - query parameters hidden. This is something we are looking into when improving the Frontend Rendering experience in the next couple of months.
For your information, an author’s name is available at: /wp-json/wp/v2/users/1
We take security and vulnerability reports very seriously.
The point you bring up does underline a possible improvement in making our users more aware of the fact that frontend rendering queries parameters are public, much like using the WordPress API.
Please let me know if you need any more information.
Just to clarify it a little. It’s mainly about the static filter values I can enter in the query block. It’s possible to enter nearly anything there. And those static values will show up on the client side. But the client can’t change them anyways.
I get it. I think I have to read into this topic to get a better understanding what data is publicly available automatically. Not only from a Security point of view but also regarding the GDPR here in the EU. But this seems to be a general WP topic.
Do the static filter values need to be on the client side because the queries are processed on the client side without doing a roundtrip to the server when filtering?
Because if there is a roundtrip I would expect the base query (with static filter values like in my first example with the password) to be kept on the server side and only the dynamic filter data (that is needed so the user can select it) to be transfered to the client.
I’m not entirely sure if I understand you right. Do you mean that when doing the request the post_password gets ignored by the query on the server side?
My first two screenshots show it is at least being sent to the client in plain text. Those were taken from a Query with Frontend Rendering enabled.
This would certainly be an improvement from a privacy/security point of view. Information the user should not or must not know would never leave the server. And Cwicly potentially will no longer need to ignore sensitive query parameters as they either never left the server (hardcoded in Query Block) or provided by the user on the frontend.
Good point @Luis . May I also suggest to have clear instructions on how to report potential vulnerabilities? We certainly shouldn’t be discussing them publicly on Discourse before they are resolved. A private message/email to the Cwicly team would be good start. Vulnerabilities can then be disclosed publicly once a fix is available.
Good point @nadim! I was uncertain if the public discourse would be the right place but wasn’t sure where else to post it. Something like private messages would be nice for this. Would the message here in the discourse work?
