[wp-hackers] Security considerations for the WP 2.7 plugin
wordpress at dd32.id.au
Wed Aug 13 05:38:27 GMT 2008
First, Let me introduce myself as DD32, or Dion, I'm the one who's been
writing the installer as part of a Google Summer of Code project, I do not
anticipate that it'll be finished by the end of the GSOC timeline, however
it'll be polished for 2.7 release, The Code has been commited to get it
out there earl in the dev cycle to get feedback, and allow a decent
ammount of time to be given to ironing out any issues, bugs, security
implications, or otherwise.
Posting this to the Trac ticket would've been more appropriate IMO at this
point of development too.
Yes, At present its assumed that the data returned from Wordpress.org has
been sanitized, And while plugins on wordpress.org get checked if they're
mearly spam, ongoing checks do not get performed, So checking that the
data is not malformed does need to be added in some places, I should point
out its currently a work in progress, I have a few major changes which
i've not yet submitted to Trac.
So Yes, That line you pointed out needs to use attribute_escape() to
ensure it cant insert any other HTML for example
However, There is also the more prominent issue of plugins conaining rogue
php code, which is going to be more dangerous than meta data containing
I do not feel that Linking to the homepage from within WordPress is a
security implication, Rather something which the user is going to expect,
The user may want to give the authors homepage(or the plugins homepage) a
squiz before deciding they trust the plugin.
The WordPress.org page links to the authors homepage, and so does the
Plugins page inside wordpress for installed plugins, Its simply too much
to expect Someone to Veto every link and page mentioned by a plugin every
day, People need to use common sense when browsing the internet.
An extra function on wordpress.org to report a plugin as "bad" and
including a reason could be a step forward for future if huge issues
arrise or if a plugin slips through the initial screening process, There's
not a huge ammount of people who currently screen plugins (Theres a reason
it takes 2 weeks for a plugin to be allowed through sometimes) - And i
know a fair few pure spam plugins get knocked back. Because as i said, Its
impossible for someone to check all the links 24/7.
On Wed, 13 Aug 2008 15:04:14 +1000, Robert Wetzlmayr
<r.wetzlmayr at gmail.com> wrote:
> Dear all,
> when rendering a result from a plugin search in the new plugin
> installer, display_plugins_table() injects a link to an URL retrieved
> from the plugins meta data (@see
> As up to this point there's no established level of trust between the
> consuming WP site and the plugin homepage URL, I wonder why this
> injection is deemed appropriate with respect to potential privacy and
> security implications.
>> From my understanding, the WP plugin repository is at least at present
> not thoroughly screened for potential malware or abusive content at
> plugins' homepages, so this deliberate linking might impose all kinds
> of threats. Please understand that I am particularly concerned with
> the presentation of search results. Any other plugin listing employs
> "trusted" plugins which are at least installed on the target site.
> Payloaded WordPress plugins already are a common SEO tactic (@see
> http://www.anty.info/2008/08/06/pingcrawl-injects-links/), and I
> wonder how long it would take before one would social-engineer
> unsuspecting WP 2.7 users as an easy prey for a plugin with
> "behind-the-scenes" functionality.
> Robert 'wet' Wetzlmayr
More information about the wp-hackers