#62088 closed enhancement (reported-upstream)
Prevent users that don't have unfiltered_html capability from adding code to custom post fields
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Security | Keywords: | |
Focuses: | ui, administration | Cc: |
Description
The custom post fields meta box will allow anyone with access to the editor to add a custom field to a post. This includes adding code, such as Javascript. Of course, adding a field is useless without something to do something with it. Until now, it's been down to plugins that may store and do anything with the code in custom fields to be responsible for any filtering of the content. However, if I may quote our own guidelines (https://developer.wordpress.org/apis/security/)...
Sanitation is okay, but validation/rejection is better.
Would it not make more sense for core to prevent unfiltered HTML from being added to custom fields if the user doesn't have the appropriate permissions (right now, that's authors - editors and upwards have it)? That way it's not down to each use of these fields to find a way to achieve this - it's not always a case of always filtering the data, as unfiltered content may be required.
I would suggest...
- Remove access to custom fields for those without the unfiltered_html capability. This is the easiest solution but most likely going to cause compatibility issues
- Make the custom fields read-only for those without the capability - it may still cause issues but at least people can view the content, and this can then come with a message explaining why it's restricted
- Allow those without the capability to make changes but then force the field to be filtered, ensuring that nothing can be done by those users that could be a concern
I'm honestly not sure which is the best solution here but what is clear is that leaving these fields open to people without the appropriate permissions could be considered a security risk, if the appropriate plugins don't take action upon them.
I'm closing this off, as I've been able to sufficiently dig into this to believe it's a security vulnerability . I have therefore reported it to HackerOne.