[wp-hackers] protecting wp-content/plugins ?

[Otto]

On 8/20/07, Sam Bauers <sam at viveka.net.au> wrote:
> But adding a blank index file does nothing to actually protect
> against detection of a known exploitable plugin. It's classic
> security through obscurity.
>
> If an attacker knows the common name for an exploitable plugin file
> and also the common location of the plugin directory, then all they
> have to do is construct the URI and request it.
> ...
> The best way to protect against this is to test for some known
> WordPress constant at the start of each plugin file, then if it is
> not there you can return a 404 HTTP Response. E.g.:

While that works, the problem here is that 90% of the plugins out
there don't actually do anything when executed directly. They define
functions and then use hooks to attach to the proper points in
Wordpress. Used exclusively, this is 100% safe coding style.

The only reason a plugin would be exploitable is if the plugin
actually executes some code of substance at include time. No plugin
should ever do this *unless* it's intended to be called directly (to
return some kind of dynamic code to the page, say, something that
outputs an image file). If the plugin actually needs to run code at
include time, it should throw it in a function and hook that to
plugins_loaded or init or some other action hook.

So the utility of a method like yours (check for ABSPATH) is limited
in scope, since a properly made plugin would never need such a check
in the first place. It's generally a fine way to partially secure a
plugin after the fact, by the end user though.