Plugins uninstall.php

Description

Should there be some more security around the use of uninstall.php, possibly giving the user the ability to chose whether to delete the options stored by the plugin or not? Even though WP_UNINSTALL_PLUGIN is one safeguard, is it the best?

As it stands now, sadly, any plugin can add/update/delete options with this function. Or it would be great to be able to add the ability for WordPress to notify the user of what options the plugin is about to delete.

I am not sure the best course of action on this, but feel that there may be some room for improvement here.

Indeed, like scribu said, you should not be concerned about the security of uninstall.php for trusted plugins, internally...

...because for a less common scenario I think we have to be concerned about the attacks from external scripts (crawlers, etc...).

Question: What happens if an external script includes wp-load.php from a WordPress instance, defines WP_UNINSTALL_PLUGIN and then includes an uninstall.php from a known plugin, for example, WP Ecommerce plugin?

As they have access to a fully loaded WordPress environment they can fully execute uninstall.php. That can be a security break. I think we should check for referer or use the nonces API too...

No, this is not a security breach. The security breach is having access to a fully loaded environment in the first place. Once they are there, they can also fully execute raw database queries and delete files all they want. Forget uninstall.php, how about $wpdb->query("DROP TABLE $wpdb->posts")?

Using the constant WP_UNINSTALL_PLUGIN is a good idea. It definitely prevents one from accessing the file directly. However, any plugin can set WP_UNINSTALL_PLUGIN and uninstall plugins at their leisure without using WP_Filesystem, which granted may not be secure, but it is also not the best or recommended method. I was just thinking that a little hardening wouldn't hurt.

I would also like to second scribu's suggestion to enable to customize the uninstall with a custom message.

As they have access to a fully loaded WordPress environment they can fully execute uninstall.php. That can be a security break. I think we should check for referer or use the nonces API too...

No, this is not a security breach. The security breach is having access to a fully loaded environment in the first place. Once they are there, they can also fully execute raw database queries and delete files all they want. Forget uninstall.php, how about $wpdb->query("DROP TABLE $wpdb->posts")?

I would also like to second scribu's suggestion to enable to customize the uninstall with a custom message.

I think it would be good for the uninstall confirmation page to be a choice between "Delete Files and Data" vs "Delete Files". The plugin's uninstall routine would only be fired if the "and Data" was chosen. This is by no means a security improvement; it's a UX improvement.

Indeed, there is no way to secure once one have access to the environment. Perhaps we could do a "security by obscurity" to wp-load.php, giving user the option to move wp-load.php one level above, as we currently allow for wp-config.php.

Indeed, there is no way to secure once one have access to the environment. Perhaps we could do a "security by obscurity" to wp-load.php, giving user the option to move wp-load.php one level above, as we currently allow for wp-config.php.

Not really, because they could always include wp-blog-header, or index, or other files. Remote "inclusion" of files is not a vulnerability. I don't think allow_url_include does what you think it does.

Moving wp-config.php up one level is not there for security. It is to use WordPress in its own folder, as an SVN external, with wp-config.php sitting beside it.