731446 - WP plugin: Private Only

Status: RESOLVED WONTFIX

(mozilla.org :: Security Assurance: Applications, task)

Description

[Jake Maul [:jakem]]

http://wordpress.org/extend/plugins/private-only/

This plugin will allow us to effectively "stage" new blogs, making them private only until such a time that the owner (and infrasec) are ready to open it up.

This is handy for at least 2 things:

1) Testing new plugins/themes in a secure manner- infrasec and content owners can test-drive them on private test blogs, without any public exposure or additional infrastructure, and with minimal IT involvement.

2) Getting IT work out of the way on a new blog launch- content owners can pre-populate the blog as desired, set up themes/plugins/etc, and flip it public when they're ready.


For starters we'd use this for the upcoming "Press Center" blog until it launches, but I suspect it would see lots of short-term usage.

Comment 1

[Jake Maul [:jakem]]

Another potential use case would be to quickly "lock" a blog in case of problems, but in such a way that we (IT or the blog owner) could still log in and fix the problem.


I also meant to mention that there are a few plugins that give us the same basic functionality:

http://wordpress.org/extend/plugins/private-only/
http://wordpress.org/extend/plugins/private-wordpress-access-control-manager/
http://premium.wpmudev.org/project/sitewide-privacy-options-for-wordpress-mu

The last seems to be the most feature-complete, but is also not free and probably more complicated. I chose the first one as my first choice because it's the most recently updated of the first 2 (can't find a date on the 3rd), it's free, and it seems very simple/straightforward compared to the other 2.

Comment 2

[Adam Muntner [:adamm] (use NEEDINFO)]

Jake, I'm starting the review for this plugin. A few observations/questions:



1.  This plugin may not be necessary to achieve the functionality you're looking for - there are more native ways which don't require using plugins which add to the attackable surface of the website, and can interact with other components in unexpected ways.

From a security perspecitve, HTTP basic auth would be preferable to the plugin. 

- Both would involve sending authentication over the same channel, whether cleartext or ssl/tls. 
Winner: Tie.

- The HTTP basic auth code is at a different layer than the application. Blocking access at this level prevents access to any application resources. Looking at the docs, I am inferring that elements and script pages belonging to other plugins and wordpress app endpoints which the plugin doesn't hook into can still be reached when using this plugin. Attackers will still be able to forcibly browse to identify the names and locations of plugins, php pages, etc, even if they can't reach them yet, by fuzzing and analyzing HTTP response codes. 
Winner: HTTP Basic Auth

- Currently, the plugin reportedly only works under WP versions up to 3.2.1. See: 
http://wordpress.org/support/topic/plugin-private-only-not-shown
Support for newer versions may or may not be forthcoming. My understanding is that plugins that don't support the latest wordpress shouldn't be used, but I'm not an expert on the policies yet. This isn't an issue for HTTP Basic Auth.
Winner: HTTP Basic Auth

If those are good enough reasons to use HTTP Basic Auth instead of the plugin, we can close the review request. If there is a good reason to use the plugin, we'll need to answer the following questions:

What is the current ecosystem of approved plugins?
Looking at the plugin in isolation statically may not reveal critical flaws which occur  
due to interaction with other plugins. Example, there appears to currently be a security 
flaw when private-only is used in coordination with buddypress. 
See: http://wordpress.org/support/topic/plugin-private-only-still-site-access-during-
registration

What theme is this expected to be used with? WP themes include PHP code which could modify default WP behavior.

Comment 3

[Jake Maul [:jakem]]

I don't think it's fair to simply declare HTTP Basic Auth as the "winner".

The problem with HTTP Basic Auth is that it's outside Wordpress... not user manageable. This means IT has to get involved any time anything is needed. We're trying to keep blogs self manageable.

As far as functionality... I have trialed it on WP 3.3.1, and while I can't replicate that specific problem in that thread, it does indeed not work properly. This pretty much kills it, IMO. Thanks for finding this report.

We still need some sort of functionality like this though, in the long run. Here's a different one that seems to do the job... possibly better suited than any of the 3 mentioned here so far: http://wordpress.org/extend/plugins/basic-authentication/. If nothing else, it claims to work with WP 3.3.1. Would you prefer a separate bug to review this one for us, as a replacement/substitute for WP Private Only? In that case this bug could be WONTFIX'd.




You can see a list of available plugins here: http://svn.mozilla.org/projects/blog.mozilla.com/trunk/wp-content/plugins/. Themes are up one level from there. Many of these have been reviewed and approved. Others were in use before infrasec required reviews on all new plugins. I don't know if infrasec ever went back and reviewed already-installed plugins... I suspect not, but mcoates would probably know for sure.

Most of them are public/upstream plugins, but I think a couple were written in-house, or at least initially maintained in-house.

I can't say for sure what other plugins any given plugin might be used with... I understand the concern, but I don't think it's really feasible for you guys to test every conceivable combination of plugins to determine what will or won't work- that sounds like an IT and infrasec nightmare. I can say in that particular example that Buddypress is not installed on blog.mozilla.com, and there are no plans to install it.


The most common themes will be our standard "Nova" theme and probably the new "One Mozilla" theme... both maintained by in-house web dev. The immediate use case for a plugin like Private Only would be for the new Press Center blog, which will launch with the "One Mozilla" theme. Craig Cook would know where to get the current code on that... I don't know if it lives in the main repo yet.

However, a few non-local themes are also available for use, and I can't guarantee that a plugin, once installed, will not end up used on some other theme. Similarly to testing all possible plugin combinations, it seems infeasible to test all plugins with all themes... to say nothing of testing all possible plugin combinations *with* all possible themes. :)

Comment 4

[Adam Muntner [:adamm] (use NEEDINFO)]

That sounds great - please open a new ticket for the basic-authentication plugin, and assign it to me.

I'm going to take on all the php reviews for a short while, as I want to create a more consistent and documented testing process for wordpress plugins/themes specifically, and php in general, because while I think wordpress is a great platform, it scares me a little, from a security perspective. :)
 
You're totally right about all possible theme/plugin combos. According to Yvan, the pre-review requirement plugins haven't been through reviews yet, so they def need to at some point. I am hoping I can streamline the process enough so that we can grind through the plugs and themes in a more in-vitro type environment, and then focus integration testing on two diff scenarios: particularly high-value, high-profile type sites, and with some popular plugins integrated into a new theme, when the new theme is tested.

Question - how can i track all wordpress related bugs that get filed? I'd like to keep an eye on them, because sometimes functional bugs = smelly code, which sometimes also means insecure code.

Comment 5

[Jake Maul [:jakem]]

Unfortunately there's no good way to keep track of all WP/PHP bugs. You can track mozilla.org::Server Operations, and mozilla.org::Server Operations: Web Operations. Those are the 2 locations that most WP-related IT bugs are likely to wind up. You could also track Websites::blog.mozilla.org... that's more of a webdev component, but there may be things in there that interest you also.

We don't generally do a lot of our own WP development, apart from themes... on rare occasions we'll customize or locally-patch a plugin if we still need it and there's no significant upstream maintenance for it.

Wiki development is in a similar state... we have our own themes (which seem to be in a perpetual state of "not enough love"), and some upstream extensions. Bugs for that are mostly in Websites::wiki.mozilla.org, plus the 2 Server Ops queue I mentioned above.

I'll close this bug out and open a new one for the "Basic Authentication" plugin.