Make WordPress Core

Opened 17 months ago

Last modified 17 months ago

#57437 new defect (bug)

Insecure Direct Object Reference in "author" parameter while making a page live Leads to Vertical Privilege Escalation on a Different Account

Reported by: f41z4n's profile f41z4n Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 6.1.1
Component: Posts, Post Types Keywords: needs-patch 2nd-opinion
Focuses: Cc:


{I've reported it on hackerone, they said its a bug, report it as a bug}

There is an Insecure Direct Object Reference in the author parameter that lets a user, set the author id to a different author, which doesnt have the rights to edit/publish the page
Steps To Reproduce:
Create a Page.
Click on settings ICON in the page in the editor.
Note that in the page section you can edit the author of page, with the list of available users.
Choose a legitimate user and intercept the request.
Now in the request there is an author parameter which has the id of user "author":id,. Change this id to a user who doesn't have the right to publish or edit the post. 6.By changing the id to a user who has no role for the wordpress, you can see that the user is now the author for the page. Thanks! Please check attached video POC for more clarity.
Make sure to check for what values of author parameter are being parsed by the backend and check if the id being passed does have the right to do so.
Privilege Escalation For an Unintended User/Low priv user
Bypass secure Design and post unwanted content from other's account.

Attachments (1)

wp_poc.mp4 (8.5 MB) - added by f41z4n 17 months ago.
Proof Of Concept Video

Change History (3)

17 months ago

Proof Of Concept Video

#1 @ironprogrammer
17 months ago

  • Component changed from Editor to Posts, Post Types
  • Focuses privacy removed
  • Keywords 2nd-opinion added

Welcome to Trac, and thank you for the report, @f41z4n!

While the author ID can be manipulated prior to posting to WordPress, the post/page edit screens perform their own user capability checks that should prevent a non-authorized user from accessing the editor.

In fact, a legitimate use of this would be for an admin to create a page, and then assign an author with the contributor role -- by default, this role cannot modify pages, and attempts to access the page editor are met with "Sorry, you are not allowed to edit this item." The same goes for assigning the author to a user with no valid role or capabilities.

That being said, having an illegitimate user set as author (like in your PoC) could have unintended consequences down the line, such as automatic access to previously assigned posts/pages if their role or caps were upgraded. Marking this ticket with 2nd-opinion for additional committer review.

#2 @peterwilsoncc
17 months ago

As mentioned above, the author dropdown is only shown to users with highly trusted roles (editors and administrators by default). The capability check is for the permission edit_others_posts or the equivalent for custom post types (CPTs).

By default WordPress only lists users with the edit_posts (or equivalent for CPTs) permission but the quick_edit_dropdown_authors_args filter is available for this to be altered to display all users, including subscribers or users without a role.
WordPress doesn't require a user have a role to be listed as an author. Some editorial workflows may wish to credit someone as the author of a post without giving them a login to the site.
As the user submitting the form is highly trusted, there is no privilege escalation.

For @ironprogrammer suggested case of a user been assigned as an author at a later date. I don't think it's a big problem, as the user is been granted trust at that point. Depending on the role they are assigned, this includes trust to edit posts they are assigned to as author.

Note: See TracTickets for help on using tickets.