My site is intended to be private, in that only registered users should be able to see anything other than the login, registration and password recovery pages (registration itself requires a code from the promotion module). At the moment, I've simply removed all permissions from the "anonymous user" role, including "access content", which makes all non-login/signup menu options disappear and every content URL I try comes up with access denied.
My concern is that there's nothing actually enforcing that modules don't show anything to users without "access content" permission, though all the modules I've tried so far seem to respect that permission - there's just no way to really *prove* it without reading the source of the module, as far as I can see.
Is there some better way to secure the site? I don't want to depend on HTTP authentication as it transmits passwords in clear (or stores them in clear, for digest auth) and I only want to use HTTPS for login pages, not all views.
Alternatively, is there some way to audit the access permissions of all menu items/callbacks automatically? I'm happy depending on the permissions if there's some way to verify what's accessible..
Thanks for any suggestions!
Comments
Nodeaccess
On sites where I've wanted to restrict user access to content unless they've logged in I've used the nodeaccess module (http://drupal.org/project/nodeaccess). It allows to configure access permissions by node type for each role.
Alex Pott
Nope..
No, you're missing the point - I'm not restricting access to some content, I'm restricting access to all content in every form. Removing the "access content" permission already stops anyone from viewing any nodes directly, but it doesn't stop, say, a badly coded search module from responding to www.example.com/lousysearch/test from coming up with a list of all the things that contain the word 'test' with a snippet of each, though the links to view the full content would not work as the node module would check.
I'm interested in stopping information leakage, not general access control.
guesses...
(i have a similar concern, but i have to trust the community(ies), and that they will report/address any issues. the security team tries very hard.)
the https stuff will probably be webserver-side (.htaccess?)... i'm pretty weak there.
since you are authenticated-only, assumptions would be:
- no caching enabled (anon only)
- you have some sort of front-page module enabled, or a static html/php page to greet your "guests" (login, go away, whatever)
- robots.txt is in place and configured
- search/search box is not enabled/accessible to anon.
search assumes indexing of some sort, which is database-centric. 3rd-party search assumes pages are exposed to be "crawled", even if they don't respect robots.txt (don't know how a search appliance would be controlled). if anonymous, can't get to the index, there are no topics/teasers to see? the "hole" would be the browser cache. please correct me if this is incorrect.
you would be correct in that it is difficult to prove data-security; all it takes is one negative incident (app, os, web server, db, post-it on a monitor...). ultimately, you would want to stick all of this on a dedicated server that you control behind a firewall with authenticated pass-thru if it is that important.
Yup, I have no caching and I
Yup, I have no caching and I use the front page module to show a simple "please log in" message to anonymous users. I don't currently have any search enabled at all (but if I do it will be a local search module), and robots.txt excludes everything.
I'm not really worried about security issues from the OS/webserver/db or from Drupal itself as I get security bulletins from the relevant people and update when needed, and beyond that it's more or less out of my hands (you can't ever prevent *every* security hole).
The issue I'm worried about is that some modules might provide pages that are visible to anonymous users, basically. Nothing in the Drupal core as far as I can see actually *requires* that modules check for the "access content" permission, so all that's needed to compromise privacy is for some module to register a callback URL that doesn't check any permissions, and for some user to guess that URL.
well...
may i suggest an inquiry to the security team about this (is this post the inquiry?), especially since you have a particular scenario in mind that can be tested.
you can probably do a "good faith" check by trying to attack your own pages exactly as you fear, and you have the advantage of knowing which nodes to try. seems to me that, as long as the modules stay within the node system, it should be okay, permission rebuilds notwithstanding. maybe this can be a suggestion for webchick's call for ghop ideas. seem to remember something about penetration tests.
good luck!
Nodes are secure..
Node pages can't be accessed because node.module refuses to show them to people without 'access content' permissions - that one is nice and easy :)
I've poked around various callback URLs provided by my installed modules and none of the ones I've tried are insecure, but there's always a risk of introducing more with a new module.
Having thought about it more, I actually suspect the way to go is a module which whitelists URL paths. I have only a handful of URLs I want to be publically visible (front page, user/login, user/register, user/password) so a tiny module that fires on init with a low weight would probably do :)