Forum Replies Created
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.
Good job prioritising this – my feedback:
It would be best if all data entry points are sanitized with the most appropriate WordPress function, so this would mean textarea would utilise ‘sanitize_textarea_field’:
For any field employing ‘wp_kses_post’ (WYSIWYG or Custom), allow developers to pass an optional sub-array of tags/protocols to be allowed using:
which is principally based on:
Enforce a minimum of ‘sanitize_textarea_field’ to all custom field types and allow developers to change this, but limited to only one of the built-in WordPress sanitization functions.
Allow developers to bypass WordPress security altogether, (obviously not advised) and implement their own sanitization.
This should only be enabled if a developer (understanding the risks) changes the default setting of sanitize:true to sanitize:custom_callback and provides a working callback function.
Hope this helps,
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.
Oops: XSS attack, not XXS attack.
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:
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:
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.
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.
Can we get an idea when this will be implemented?
I would be interested in an integration between Metabox and Buddypress.
There is a plugin which “syncs” (i.e. duplicates) user/xprofile fields:
But it would be better to natively update the fields like Gravity Forms:
Hope this can be added to the development roadmap.
I suggested a boolean for bi-directional (reciprocal) relationships in this post:
Hope this helps,