Sanitization of Fields input

Hi Anh,

I have not tested it yet, but in my opinion, fields should be sanitized out of the box.

Each field should be sanitized according to its type.

If some developer do not want to use default sanitization and want to allow script tags or other similar dangerous input, he should do it by explicitly explaining that he dont want to use default sanitization.

He may use this sanitization_callback in that case.

I see that your plugin no only skipping sanitization but also not validating input.

e.g. select field input does not check if the provided value is one of the value of options.
(Let me know if its doing so)

I had purchased the bundle before and wanted to use this in my plugin now, but i am not getting comfortable with this practice.

I know you have two problems if you apply the default sanitization in your next version:

Problem 1: Current developers may be using the fields knowing that tags are not stripped off. If you apply default sanitization, their plugins may not behave as expected as all tags will be sanitized.

Problem 2: It may be extra coding hours of debugging and checking.

Grievance: If you do not apply default sanitization, then sites are at risk of XSS at minimum.

Solution: You plan it for the major release and let your developers know that fields will be sanitized automatically according to their type, If they dont want to use default sanitization, they have two options:

1. they can write no_sanitize for the sanitize_callback value and if such value found, you may simple return the value here: https://github.com/wpmetabox/meta-box/blob/e0aa9753a74603fc4a6348f4638c324e48f196f7/inc/sanitizer.php#L51

2. Or, they can provide their own sanitization function in sanitize_callback

In any case, there has to be some default sanitization at all cost.
as @david.h said, it should be white-list approach as compared to blaclist approach.

Let me know your thoughts and plan on this so that i may decide whether to use this tool in my plugin or not.

Regards,

Rao Abid

Hi Anh,

Thanks for the reply.

I am a plugin developer myself and Problem 1 was the main concern when you push something like this that can affect current users.

i myself has written this helper class:
https://github.com/boospot/boo-settings-helper

and also author of this course:
https://www.udemy.com/wordpress-plugin-development-using-boilerplate/

I can well understand your situation as the authour of this framework and also the grievance of the situation where current 400k+ sites are using this framework without sanitization.

I bet more than 50% of these developers are not using the sanitization filter you have referred before, simply due to one reason: They are using this framework for its "plug-and-play" nature so that they dont have to worry about setting up (explicit), saving (explicit) and sanitization (implicit) of metaboxes.

Since its an established framework, so it will (soon) become the next target of Security researchers and i dont want metabox.io to make to headlines as some plugins have already done like "Revolution Slider", "Social Media Buttons", "Yellow Pencils" and many more as pointed here: https://www.pluginvulnerabilities.com/blog/

Any such news can seriously undermine the reputation of the framework.

In my opinion, following solutions are on the table:

1. We provide a value like this for default sanitization:
   'sanitize_callback => 'default'
   Any developer using this will get default sanitization as per the nature of the field.
   [Workable but has extra typing for each field defination and make the repeating code]

2. We can provide a constant based sanitiation like a constant is defined in wp-config.php or the plugin piggy back to the framework. if that constant is there, default sanitization will prevail.
   Example: METABOX_FIELDS_SANITIZE_DEFAULT = true
   [Most Desirable as default sanitization behavior can kick-in with just one Constant definition]

3. We push this change is major future realeas and let the users know that its coming and they can modify their code accordingly. WooCommerce does this all the time and Developers are required to make their code compatible.
   [This solutin is most secure and will definitly raise support tickets once pushed but its the best path to follow. Any person not using default sanitization should conciously explicitly configurs in the field config array]

Let me know your thoughts on this.

Cheers,

Rao