views:

94

answers:

1

There probably is some solution to this, whether it involves code running on just the wordpress installation or a combination of a wordpress installation and a master server I am not sure yet, but please remember not to have tunnel vision and consider any and all possible solutions:

The scenario is this: A WordPress plugin (plugin-A) that manages some sort of valuable data (something that the admin would not want stolen), lets say, lead data with user's name and email addresses, the plugin uses its own db tables.

Other than the obvious (which is the admin installing plugin-B, not knowing its malicious intent), what is to prevent another WordPress plugin (plugin-B) from accessing plugin-A data or hacking plugin-A files to circumvent security.

+2  A: 

Trouble is, you'll be trying to protect the system from something that is running within it - the very nature of a WordPress plugin is that it has;

  • Database name, username and password, along with...
  • An active database connnection, with which it could easily query to find all tables and their structures, no matter how obscure
  • It is running inside the WordPress script, and has access to all globals, functions and classes

If the data you're working with is that sensitive, or you simply don't want to run the risk, don't allow plugins (at least not without checking the source code first).

TheDeadMedic
ya, kinda what i figured ... all the scenarios i ran in my head ended up with the rogue plugin-B simply overwriting plugin-A source code...
farinspace
is it possible to lock via server configuration ? so no access from a folder a plugin into another folder of pluggin (via htdoc or something). every server request has its referrer is it ?
justjoe
Yeah, if you're running *nix you could lock down file permissions, but his database is still wide open.
TheDeadMedic
even using file perms on *nix might not work, doesn't it all depend on what user the PHP process is running as?
farinspace