Meta Box

Hi,

I am still awaiting this feature and cannot use MetaBox without it.

On March 18 2020 Anh said it was planned for completion in 2020, and on April 28 2020 Long said it was on its way.

However, over one year later there's still no update and MetaBox are not providing an insight on any progress.

It is an essential feature for a professional CMS framework akin to Drupal.

Please can Anh or Long provide a realistic schedule for at least the first public alpha or beta release.

Thanks and regards,
David

Hi Anh,

I had server hacked once (through a poorly secured web app), so now I'm far more careful.

Try reading through:

https://www.cisecurity.org/controls/cis-controls-list/

Specifically, Control 4 and the principal of least privilege:

https://www.cisecurity.org/spotlight/ei-isac-cybersecurity-spotlight-principle-of-least-privilege/

IMO, this principle should be applied to all dev scenarios, including sanitize_textarea or wp_kses.

Thanks

Ok,

I think we are focusing on entirely differing viewpoints: back-end vs front-end.

My understanding is that historically Metabox allowed HTML to be posted in textarea fields to aid developers, as Anh says in #19102. However, my concern is for the thousands of new/novice developers who are now using Metabox without detailed knowledge of what is happening in the background.

Since the introduction of MB FrontEnd Submission, many people will be creating public facing front-end forms (e.g. contact, listings, etc) many of which can be submitted without credentials or authentication. Thus, removing all tags and only allowing text in a textarea is what any reasonable person would expect from framework that proclaims "The sleepless nights of endless coding are over". If true, this is a comforting statement, but to be so Metabox must keep patrons' security above aesthetics, ease of function or endlessly accommodating backwards compatibility.

For all the time we've spent discussing this, there could have been a number of relatively simple workarounds implemented - e.g. passing MB FrontEnd Submission textarea fields through sanitize_textarea_field before the default Metabox sanitization of wp_kses_post kicks in - clearly this is not carefully considered solution, but it would work for an interim period of time.

In the WordPress ecosystem, we have all encountered too many sites that have been compromised by plugins devoid of appropriate or adequate security, so please let's try and start something new here - security comes first.

I hope that this thread has opened discussion and thinking that might not have occurred otherwise.

All the best

Ok, although I'm not really sure what feedback you are looking for?

1) sanitize_textarea_field is for a textarea field which should be used as per https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea

2) I'm not sure this would be more complicated, its simply a nested array passed to a function which you have already outlined.

Hi Anh,

Having dry-run the code, I pleased to see this heading in the right direction. Remember to keep this on your to-do list, because security should not be a one-time "set it and forget it" thing, but a constant test, evolution, improvement and refinement of the requirements.

Before release, I suggest you employ some white-hat tactics and ask a core-team (maybe from your Facebook group) to try thwarting or circumventing the sanitization using combinations of complex field groups, custom tables, front-end posting and carefully malformed data.

Thanks,
David

Ok,

But I'm not sure most of your customers will know what they need to do - especially those using MB User Profile and MB FrontEnd Submission where (potentially) anonymous or less trusted users could abuse the system.

I understand your concern regarding managing a whitelist for HTML tags/attributes, but wp_kses_post should handle this without any further configuration required:

https://codex.wordpress.org/Function_Reference/wp_kses_post

Alternatively, at least baseline strip javascript tags/code and links containing javascript as these should never be included in post markup, and can used to create XXS attacks which maliciously affect users browsing the site.

If correct, this is quite concerning.

Standard WordPress security should be enabled by default in any plugin or snippet that uses the ecosystem - it should be possible to override this with an option but this should not be necessary in normal circumstances.

Anh, please can you confirm whether this is isolated or across the board.

I would be interested in an integration between Metabox and Buddypress.

There is a plugin which "syncs" (i.e. duplicates) user/xprofile fields:

https://en-gb.wordpress.org/plugins/bp2wp-full-sync/

But it would be better to natively update the fields like Gravity Forms:

https://docs.gravityforms.com/user-registration-add-on/#buddypress-integration

Hope this can be added to the development roadmap.

Regards