Custom Fields
Re-Envisioned › Support › General › Sanitization of Fields input

Viewing 10 replies - 1 through 10 (of 19 total)
1 2
  • Author
    Replies
  • August 4, 2019 at 1:40 AM #15593
    david.h
    Participant

    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.

    August 4, 2019 at 2:55 PM #15596
    Anh Tran
    Keymaster

    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' );
    August 4, 2019 at 5:31 PM #15599
    david.h
    Participant

    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_kses

    Additionally, 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.

    August 4, 2019 at 9:29 PM #15601
    Anh Tran
    Keymaster

    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_callback parameter to the field settings. So developers can decide what and how to sanitize value.

    August 4, 2019 at 9:59 PM #15602
    david.h
    Participant

    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.

    August 4, 2019 at 10:14 PM #15603
    david.h
    Participant

    Oops: XSS attack, not XXS attack.

    August 5, 2019 at 1:47 PM #15604
    Anh Tran
    Keymaster

    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.

    August 7, 2019 at 12:46 PM #15639
    Anh Tran
    Keymaster

    I’ve added support for sanitize_callback here. Please try it and let me know if you need any improvement.

    August 9, 2019 at 10:34 PM #15656
    Rao Abid
    Participant

    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

    August 10, 2019 at 2:50 PM #15663
    Anh Tran
    Keymaster

    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.

  • Author
    Replies
Viewing 10 replies - 1 through 10 (of 19 total)
1 2
  • You must be logged in to reply to this topic.