This topic contains 19 replies, has 3 voices, and was last updated by 
Anh Tran 2 months ago.
-
Topic
-
Hi Support,
I see that the plugin is not sanitizing user input as per field type.
For instance, text field should be sanitized using the WordPress built-in function
sanitize_text_field()function.
Link: https://developer.wordpress.org/reference/functions/sanitize_text_field/Here is the Recordit Screencast for what i am trying to show:
https://recordit.co/wX2MWS8yjENotice that if a user enters a script, it gets saved to Database as-is without going through text field sanitization.
I understand not every developer want to run it through this method. Is there a way for me to run the input through these sanitization methods?something like this where we can add the sanitization method to use as parameter in field array config:
https://github.com/boospot/boo-settings-helper/wiki/Fields-Configuration
Notice thesanitize_callbackarray parameter.
Its usage is defined here:
https://github.com/boospot/boo-settings-helper/wiki/Fields-Configuration#sanitize_callbackSimilar goes with other field types.
Let me know if you need more clarification on this.
-
Replies
-
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.
Hi Rao and David,
The plugin sanitize values for some field types only (file_input, email, url, oembed, checkbox and switch). You can see the code for that here. For other fields, to let users able to enter some HTML, we don’t force a sanitize callback. But you can sanitize the value with this code:
add_filter( 'rwmb_text_sanitize', 'sanitize_text_field' ); add_filter( 'rwmb_{$field_type}_sanitize', 'your_sanitize_callback' );Hi Anh,
As firewalls do, you cannot go wrong implementing a default deny policy when coding. Thus, unless you specifically allow something, you deny it – like whitelisting.
The minimum santization you should incorporate for fields which might contain HTML is KSES:
https://codex.wordpress.org/Function_Reference/wp_kses
https://codex.wordpress.org/Function_Reference/wp_kses_post
https://codex.wordpress.org/Plugin_API/Filter_Reference/pre_ksesAdditionally, create separate allowed HTML tag arrays for back-end admins (more open) and front-end users (less open) which can be amended as per requirements.
Hi David,
Making a whitelist of HTML tags might be tricky, since there are a lot of them. For example, if you have a textarea/wysiwyg field, then it nearly impossible to define those tags. Besides, I want to offer flexibility to developers and let them decide what need to be sanitized.
I’ll add
sanitize_callbackparameter to the field settings. So developers can decide what and how to sanitize value.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.
Oops: XSS attack, not XXS attack.
I understand. However, there are some cases where people really want to enter script, like a textarea field for entering header / footer code (in a page settings).
I just want to provide the maximum flexibility to users, while developers still can restrict the content if they want. That’s how a library should do. It’s the same as the Customizer API where developers still have to define their own sanitize callback.
I’ve added support for
sanitize_callbackhere. Please try it and let me know if you need any improvement.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_callbackin that case.I see that your plugin no only skipping sanitization but also not validating input.
e.g.
selectfield 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:
- they can write
no_sanitizefor thesanitize_callbackvalue and if such value found, you may simple return the value here: https://github.com/wpmetabox/meta-box/blob/e0aa9753a74603fc4a6348f4638c324e48f196f7/inc/sanitizer.php#L51 -
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 Rao,
I really appreciate your thoughts on this.
I understand the need for default sanitization. And believe me, this is what I also want to add to the plugin.
You also pointed out a very important point (point 1), which makes me not pushing the santization so hard. Meta Box is now actively used on 400k+ websites. Any change we make will affect these huge amount of websites. I can’t notify the developers (there’s no way to let them know because WordPress.org doesn’t provide any way to contact to them). So, I decide to not implement a forced / opinionated sanitization at the moment. I have to be very careful about this.
Another thing that people should consider is: Meta Box is not an end-user tools. It’s a tool for developers which provides API. So there’s nothing like Meta Box –> Users, but it’s more like Meta Box –> Developers –> Users. Because of this, developers understand which kind of data they want their users to enter. And thus, a sanitization callback fits this situation.
If you’re building a new plugin / solution using Meta Box, why don’t you implement this with just a few lines of code instead of depending the default sanitization which might not work smoothly in all cases?
There are also a few things regarding sanitization in WordPress, that I think worth mentioning:
- Admins can enter script and style in the post content, regardless the santiziation of wp_kses_post.
- Customizer API requires (not strictly) developers to enter santiziation callback. If no sanitization callback, then what users enter will be used.
- wp_insert_post doesn’t do any sanitization for the content when inserting the post programmatically.
Anyway, there is a default sanitization for some fields (email, url, file_input, checkboxes). For other fields, due to the nature of the complexity, I haven’t implemented that. If you have any idea on which proper sanitization for each field type, please let me know.
- they can write
You must be logged in to reply to this topic.