Make WordPress Core

Opened 10 months ago

Closed 10 months ago

Last modified 9 months ago

#62088 closed enhancement (reported-upstream)

Prevent users that don't have unfiltered_html capability from adding code to custom post fields

Reported by: dartiss's profile dartiss 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...

  1. 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
  2. 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
  3. 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.

Change History (2)

#1 @dartiss
10 months ago

  • Resolution set to reported-upstream
  • Status changed from new to closed

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.

#2 @johnbillion
9 months ago

  • Component changed from Editor to Security
  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.