Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I have added some custom user options to the profile page on my site, and most are all OK for the user to modify themselves. These options live in their own section. The users have read access and are able to visit the backend and change some settings in their profiles.

There is another per-user option that I do not want the user to ever be able to modify directly. I have the code that creates that option group and section check if the user can edit other users' profiles. If they cannot, the section and the setting are not registered with WordPress (and thus not displayed on the profile page). Only someone with the proper permission can visit to the edit profile page, view, and change the setting via the backend.

Can a malicious user ever submit additional POST data with an otherwise valid profile update and set an option that wasn't registered on the page, but does exist in the database? How certain/solid is this protection? Are there any known problems with it?

share|improve this question
1  
+1 Good question - and welcome to WPSE :) –  kaiser Oct 15 '12 at 13:52

1 Answer 1

up vote 6 down vote accepted

You should (if available) submit the code you are working with, even if just a snippet, so we can assess your process in relation to your question.

The short answer however is YES, it is safe, so long as you,

  • prevent input fields being displayed on user profile page for certain user roles
  • prevent unauthorized users from saving user meta to the database

First:

If the input fields which pertain the user meta data are hidden from specific user roles on the user profile page then "attacker" would need to guess what the meta_key is for the field in which they wish to populate. Good luck with that!

Second to that:

If they were able to guess the meta_key in question, they'd then need to run functions pertaining to update_user_meta or add_user_meta. The only way they can do that is if,

  • they can see the input fields
  • you've failed to check for user capabilities via conditional statements.

...which then would allow the user to save or edit those user meta fields which should otherwise be hidden not added/rendered to the request on screen.

We'll assume that,

  • you provide no other means for users to run arbitrary scripts of their own choosing anywhere else on your site

...which mitigates the risk of an attack happening in the first place.

A start would be to wrap functions related to adding or editing user meta data in the current_user_can function.

if ( current_user_can('edit_users') ) {

    //show input fields function

    //allow input fields to be updated function
}

This checks whether the current user can actually edit_users which by default is only available to Super Administrators and Administrators unless you've otherwise allowed this capability to another user role of your choosing.

This isn't the only check you may wish to make, but its certainly one of the more important ones to include for safety.

share|improve this answer
1  
+1 Informative. Good question, also. –  Johannes Pille Oct 15 '12 at 4:51
    
+1 But one note: "hidden" should be exchanged with "not added/rendered to the request" just to avoid confusion with CSS display: none;. Another idea: manage_options capability is also only available for admins. Maybe this could be added to the check to be double sure ;) –  kaiser Oct 15 '12 at 13:50
1  
@kaiser Done... –  userabuser Oct 15 '12 at 13:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.