CiviCRM Community Forums (archive)

*

News:

Have a question about CiviCRM?
Get it answered quickly at the new
CiviCRM Stack Exchange Q+A site

This forum was archived on 25 November 2017. Learn more.
How to get involved.
What to do if you think you've found a bug.



  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Developer Discussion (Moderator: Donald Lobo) »
  • Security Issue with Joomla and Profiles - patch 1
Pages: [1]

Author Topic: Security Issue with Joomla and Profiles - patch 1  (Read 3679 times)

rogerco

  • I post occasionally
  • **
  • Posts: 66
  • Karma: 5
Security Issue with Joomla and Profiles - patch 1
July 30, 2009, 02:58:00 am
v2.2.7 and earlier allow any site visitor to construct a url to see any profile information that is exposed on your site. If you have edit profiles this includes full editing of your data - hence front-end editing has been disallowed in 2.2.7 Joomla.

There is a further privacy issue, however, in that a casual visitor can view any contact information that is available in a profile.

If you do not need the public to see any CiviCRMdata - eg if you are running a members-only site, where only members can register and login and the public never see any pages with CiviCRM content - then here is a patch that at least stops the public being able to steal your contact data.

insert the following in civicrm.php in [joomlaroot]/components/com_civicrm around line 15 after the test for php v5
Code: [Select]
//check logged in - if not 403
$user = JFactory::getUser( );
if ( $user->get('guest')) {
JError::raiseError( 403, JText::_('Access Forbidden') );
return;
}
This will allow only logged in users to invoke civicrm and prevents the public from directly entering calls to civicrm component urls.

You could of course provide a nicer redirect than a bare 403

This is not a complete solution, as any logged in user can still view any contact's data on a profile by constructing the appropriate url - but in a member's only situation this might be less of an issue so long as all of you members have agreed with your data controller policy of sharing their information with other members (beware the Data Protection Act)

It looks like you could add logic in the civicrm_invoke() function to restrict editing (if you re-enable it as per v2.2.6 and earlier) to particular users or groups, but again users could bypass that by constructing the url directly.

I *think* this works ok - certainly the direct urls that were working on one of my sites now generate 403's, but logged in users' access to profile forms still works. I'd like to hear comments from others.

Hope this helps someone.
Cheers
RogerCO
« Last Edit: July 30, 2009, 03:03:22 am by rogerco »

lcdweb

  • Forum Godess / God
  • I live on this forum
  • *****
  • Posts: 1620
  • Karma: 116
    • www.lcdservices.biz
  • CiviCRM version: many versions...
  • CMS version: Joomla/Drupal
  • MySQL version: 5.1+
  • PHP version: 5.2+
Re: Security Issue with Joomla and Profiles - patch 1
July 30, 2009, 05:10:31 am
Roger,

You bring up a good point, that I'd been thinking about lately. Using SEF for Civi links (creating a menu item) is one way to discourage intrusion. But it only discourages -- doesn't block.

What do you mean when you say "front-end editing has been disallowed in 2.2.7"?

I'm not sure of the best solution to the big picture. I think it might be helpful to have an option in the profile settings that enables the profile for direct frontend viewing and editing -- otherwise they are locked down. The restriction would need to be limited to "direct" profile viewing though, as you may have profiles used in events or contrib forms that you don't want direct access to, but are available via the parent page. I know in my use cases I typically only have a handful of profiles that are front-facing. The rest are used with event/contrib or admin purposes.

That wouldn't solve the access rights issue though (public/registered/special).

-Brian
support CiviCRM through 'make it happen' initiatives!
http://civicrm.org/mih

rogerco

  • I post occasionally
  • **
  • Posts: 66
  • Karma: 5
Re: Security Issue with Joomla and Profiles - patch 1
July 30, 2009, 05:45:13 am
Hi Brian,

Quote from: lcdweb on July 30, 2009, 05:10:31 am
What do you mean when you say "front-end editing has been disallowed in 2.2.7"?

See http://forum.civicrm.org/index.php/topic,9087.msg39136.html#msg39136 and links there-from. In 2.2.7 the only front end editing that is allowed is of your own details.

Looking a bit more into civicrm.php and thinking about the patch I made a year ago to allow Civi Groups to be used for access control I am becoming convinced that this Joomla front-end part of Civi needs some major work.

It would be nice to have various things set through menu and component parameters including access control using either/or/both Joomla levels (to be extended to full ACL in 1.6 I hear) and Civi Groups or Civi's own ACL. The first two are easy to do and don't require any changes to the Civi core.

It would also be good to have menu parameters for into and outro text above and below the CiviCRM profile display so that you could have different text for the same profile on different menu entries.

Most fundamentally this is the place to try and block people putting fancy query strings in to access profiles that they shouldn't be able to see. I envisage something like a list of Joomla user id's or user levels associated with each Civi gid (profile) used to block access to that gid.

At its simplest it could be a single component parameter containing a list of gid's which are publicly visible; a guest user trying a url with any other gid would be thrown out.

Perhaps then extend this to a three level test - public gid's, registered gid's and special gid's

This would require no change to the profile settings in core Civi CRM so could be implemented as a quick modification to the Joomla only files in the Joomla version.

I'm not familiar enough (at all) with how Drupal works to know if these changes would make any sense in the Drupal world, clearly there might be regression implications for any changes in files that are common to both J and D (ie the Civi Core)

RogerCO



Dave Greenberg

  • Administrator
  • I’m (like) Lobo ;)
  • *****
  • Posts: 5760
  • Karma: 226
    • My CiviCRM Blog
Re: Security Issue with Joomla and Profiles - patch 1
July 30, 2009, 08:43:48 am
Roger - We are looking into the problem and working on a solution. We should be able to post an update later today.

Regarding the patch below... I think this would also prevent anonymous visitors from accessing CiviCRM contribution and event registration pages - so folks should consider this before implementing it.

...dave

Quote from: rogerco on July 30, 2009, 02:58:00 am
If you do not need the public to see any CiviCRMdata - eg if you are running a members-only site, where only members can register and login and the public never see any pages with CiviCRM content - then here is a patch that at least stops the public being able to steal your contact data.

insert the following in civicrm.php in [joomlaroot]/components/com_civicrm around line 15 after the test for php v5
Code: [Select]
//check logged in - if not 403
$user = JFactory::getUser( );
if ( $user->get('guest')) {
JError::raiseError( 403, JText::_('Access Forbidden') );
return;
}
This will allow only logged in users to invoke civicrm and prevents the public from directly entering calls to civicrm component urls.

Protect your investment in CiviCRM by  becoming a Member!

rogerco

  • I post occasionally
  • **
  • Posts: 66
  • Karma: 5
Re: Security Issue with Joomla and Profiles - patch 1
July 30, 2009, 08:52:54 am
Quote from: Dave Greenberg on July 30, 2009, 08:43:48 am

Regarding the patch below... I think this would also prevent anonymous visitors from accessing CiviCRM contribution and event registration pages - so folks should consider this before implementing it.

...dave


Yes. I did say that, although not very explicitly. It will prevent public access to ANY CiviCRM page. Only ok if (like one of my sites) you are not using public contribution and event registration facilities (or any other facility you want people to see without logging in)

My preferred solution would be to have a Jooomla component parameter to define which gid's were allowed public access and check for that instead. But this works as a quick fix if you are not using public visible civi pages.

RogerCO

lcdweb

  • Forum Godess / God
  • I live on this forum
  • *****
  • Posts: 1620
  • Karma: 116
    • www.lcdservices.biz
  • CiviCRM version: many versions...
  • CMS version: Joomla/Drupal
  • MySQL version: 5.1+
  • PHP version: 5.2+
Re: Security Issue with Joomla and Profiles - patch 1
July 30, 2009, 10:14:46 am
I agree with Roger --
But that setting would need to be on a per-profile/contrib page/event reg basis -- not a universal setting. So Profile ID=4 would be accessible to the "registered" ACL group in Joomla, while Contrib Page ID=2 would be publicly available.
support CiviCRM through 'make it happen' initiatives!
http://civicrm.org/mih

Donald Lobo

  • Administrator
  • I’m (like) Lobo ;)
  • *****
  • Posts: 15963
  • Karma: 470
    • CiviCRM site
  • CiviCRM version: 4.2+
  • CMS version: Drupal 7, Joomla 2.5+
  • MySQL version: 5.5.x
  • PHP version: 5.4.x
Re: Security Issue with Joomla and Profiles - patch 1
July 30, 2009, 11:58:58 am
So a couple of thoughts and a few issues.

1. Thanx to roger's investigation, we uncovered some bugs and have filed issues and will fix them for 2.2.8 (CRM-4822, CRM-4821). Some patches for this are already in svn. We will post "diff" info as soon as possible for folks who want to patch their installs prior to 2.2.8 release next week (probably later today PDT).

2. Note that profiles by definition expose your database information to the world. In joomla due to lack of permissioning and ACL's all front end users have access to all profiles. Admins should be aware of this and should use the visibility settings wisely (User and User Admin visibility prevent folks from seeing information in the frontend for other folks in the listings page. CRM-4821 fixes the bug in the view page).

3. CRM-4822 address the issue of only displaying profile information for contacts in the group restricted by "limit listings to group" setting.

4. A fix in v2.2.7 (CRM-4688) prevents folks from editing profile entries that are not part of their contact record

5. In the medium term, integrating ACL's within joomla (http://civicrm.org/node/602) is a better more integrated approach and will get joomla version of civicrm on par with Drupal and Standalone with regard to permissioning. So would be great for the joomla community of users to step up and help make this happen.

6. Note that CiviCRM ACL's already have support for profiles and you can restrict which ACL groups can access which CiviCRM profiles (in Drupal and Standalone).

7. Frontend CiviCRM for joomla has limited / no permissioning. (only a few urls are exposed). Front end users have access to all the functionality in the exposed urls.

lobo
« Last Edit: July 30, 2009, 12:09:50 pm by Dave Greenberg »
A new CiviCRM Q&A resource needs YOUR help to get started. Visit our StackExchange proposed site, sign up and vote on 5 questions

Dave Greenberg

  • Administrator
  • I’m (like) Lobo ;)
  • *****
  • Posts: 5760
  • Karma: 226
    • My CiviCRM Blog
Re: Security Issue with Joomla and Profiles - patch 1
July 30, 2009, 12:20:50 pm
Summarizing the expected behavior for front-end Profiles in Joomla! once the two new fixes are in place. I'll post the "diffs" for patching as soon as I can.

* Profile Field Visibility : "User and User Admin" setting restricts VIEW access to this profile field / data for all front-end users EXCEPT a logged in user viewing their own contact record (e.g. the contact record linked to their Joomla user record). Set all fields to this value if you don't want "public" VIEW access to any profile fields.

* Profile Settings : "Limit listings to Group" restricts VIEW access to the record level. Only contacts in the selected group are listed in search results. AND (with CRM-4822) only those contact records can be accessed directly via URL for VIEWing. Attempts to view any other records will result in redirect to front-end home page. You can create an empty group and use that for this setting if you want to ensure that no contacts are viewable at the record level.

* Logged in front-end users can EDIT their own contact record in a profile form when you provide them a direct link to civicrm/profile/edit. This is the only profile EDIT functionality available in the front-end.



 
Protect your investment in CiviCRM by  becoming a Member!

rogerco

  • I post occasionally
  • **
  • Posts: 66
  • Karma: 5
Re: Security Issue with Joomla and Profiles - patch 1
July 30, 2009, 03:45:53 pm
Thanks David and Donald, that sounds like it might cover most of the issues - but in doing so we are crippling Joomla use of CiviCRM.

I certainly hadn't realised that profiles effectively expose the information to the world - this, in my world at least, is most undesirable.

The statement "in Joomla due to lack of permissioning and ACLs all front-end users have access to all profiles" simply is not (or need not) be true. I think there is a fundamental misunderstanding of how Joomla is used going on here.

Firstly there is a simple ACL/permissioning system in Joomla based on public/registered/special with special further segmented into author/editor/publisher and additional backend admin levels. Components quite routinely use these categories to restrict access to functions. There are also components which significantly extend this or add their own permission groups - eg Community Builder and DocMan to name 2 at random.

Perhaps we should spool back to first principles and understand that in most (nearly all those I have dealt with) Joomla installs the backend access is only used for website admin. It is pretty unusual to give backend access to a user with an organisational function like looking after a document library or administering a contact database - most well formed components would expose the necessary routines for this organisational admin in the frontend, and reserve backend access for users needing to make structural changes.

So using CiviCRM in a Joomla environment I absolutely expect to be able to grant some users (perhaps the 'editors' Joomla category) the ability to edit some or all contact information, and other users (eg registered) the ability to edit some of their own information and view some others, and other users (eg public/guests) far more limited access - perhaps only to signup/contribute and register for events.

The situation you propose effectively prevents this from happening. The restriction to only allow editing of contacts other than the users own record, to the backend is just not viable. The profile field visibility as described by Dave is, I think, the current situation which is ok, as is the limit listings to Group profile setting with the addition that you now will not be able to trick it into showing other contacts not in the group.

I don't hear any proposal to address the most fundamental problem though which is the statement that profiles by definition expose your information to the world through the front end. In the world of concerns about privacy of personal information, data protection, and identity theft this is simply not acceptable and makes CiviCRM unusable on the Joomla front end.

As I understand it even with the proposed changes any public visitor would still be able to enter a url that referenced a valid profile and be able to see the listing and the contact details in that profile - this simply can not be allowed.

What is even worse is that this applies to any profile at all, even if you haven't actually exposed it in the front end through a menu entry.

The good news however is that this can very easily be fixed without making any changes to the core Civi functionality. The way Joomla works all access to a component on the front end is through its front-end part - in our case components/com_civicrm/civicrm.php and its associated views. This works by invoking the core Civi functions common to both Joomla and Drupal, but you could not easily call those core functions without going through the front-end component.

I don't think there is any absolute need at this stage to implement Civi ACL for Joomla - it would be nice to have, but the immediate problems need fixing first in the v2.x series.

So the solution it seems to me lies in civicrm.php and its associated view. By imposing access control there you can safely re-allow editing in the front end and let the Joomla site admin manage it through standard Joomla component and menu parameters (defined in the xml files).

Please think about this some more and don't continue to cripple the Joomla front end - it is quite unnecessary I think.

I am travelling for the next week but will be very happy to work on the Joomla specific bits to allow full functionality on the front end.

It may be that I have misunderstood some more fundamental problem with the core Civi stuff, in which case please explain your thinking some more.

I'd be especially interested to hear from other Joomla users whether they are a) using profiles to enable contacts to see and/or edit other contacts details, b) whether you knew that this meant that anyone could see those details, c) whether you think this is an issue - maybe it is just a UK concern about data protection and privacy, and d) whether you think the solution of not being able to use profiles with Joomla is acceptable. Also is my initial description of the difference between Joomla front-end and back-end access typical - do you routinely allow users back-end access to your sites?

Sorry for the very long post, but this seems to me a critical issue that I would like to help fix. If it is not of any concern to others then I'll just go away and hack out a workaround solution for myself - which will include needing to downgrade to v2.2.6 to get the editing facility back.

Cheers
RogerCO

lcdweb

  • Forum Godess / God
  • I live on this forum
  • *****
  • Posts: 1620
  • Karma: 116
    • www.lcdservices.biz
  • CiviCRM version: many versions...
  • CMS version: Joomla/Drupal
  • MySQL version: 5.1+
  • PHP version: 5.2+
Re: Security Issue with Joomla and Profiles - patch 1
July 30, 2009, 04:24:20 pm
Roger,
I think there's some misunderstanding. As I read Dave/Lobo's post --

Code: [Select]
I don't hear any proposal to address the most fundamental problem though which is the statement that profiles by definition expose your information to the world through the front end. In the world of concerns about privacy of personal information, data protection, and identity theft this is simply not acceptable and makes CiviCRM unusable on the Joomla front end.
If a profile's fields are set to the user/user admin option, then *only* the logged in user may view and edit the field. The restriction is placed on the field level, and that is where the security is created. Fields set to public user or public user listings, are (as the name suggests), publicly available.

That doesn't address the desire to have ACL restrictions between public and registered users for things like a profile listing, but it does ensure some level of security.

Re: allowing a user to edit other users' records -- that seems to be the piece that is now missing in the Joomla puzzle. Personally, I've not used that much (though ironically I have a site that I was looking to implement that functionality on sometime soon).

I think Lobo/Dave are trying to plug a security hole in the immediate release, and that plugging the hole is more important than restoring functionality. But obviously we need to find a way to restore that functionality.

I don't think that's trivial. Although you can control access using the J access levels for a Civi menu item, there's no clear way to do that for a Civi page that is direct-linked in an article or module.
support CiviCRM through 'make it happen' initiatives!
http://civicrm.org/mih

Donald Lobo

  • Administrator
  • I’m (like) Lobo ;)
  • *****
  • Posts: 15963
  • Karma: 470
    • CiviCRM site
  • CiviCRM version: 4.2+
  • CMS version: Drupal 7, Joomla 2.5+
  • MySQL version: 5.5.x
  • PHP version: 5.4.x
Re: Security Issue with Joomla and Profiles - patch 1
July 30, 2009, 05:16:48 pm

a couple of clarifications:

1. I dont think we are crippling anything within Joomla, we are closing a few of the holes that expose more data than they really should across all CMS

2. CiviCRM's permissioning model on Joomla is primitive is fairly well known. Hence the blog post by Sarah to get ACL support for joomla. That should address a lot of your concerns.

3. If you think that there are simple patches to civicrm.php that will help improve things from a security/functionality patches in Joomla, please do submit your patches for discussion. We'd be happy to take a look at it and potentially integrate it with a 3.x release of CiviCRM

4. I find it a bit strange to hear statements like: "I absolutely expect to be able ...." or "...than the users own record, to the backend is just not viable". I think we have admitted that the lack of permissioning support in Joomla is a big deal. However as an open source project, we'd love it if the community steps up and helps the product meet "expectations" and make things "viable". The financial support for the permissioning support in joomla is not breaking any records unforunately :(

If you think it will help you and future users to make it more clear about the exposure of data within profiles, please do update the documentation and clarify things. we will review the changes, but your input and concerns on those documents would benefit a few people. yes, profiles are powerful, at the same time they can expose a fair amount of data if not configured properly and/or if bugs are present

lobo

lobo


A new CiviCRM Q&A resource needs YOUR help to get started. Visit our StackExchange proposed site, sign up and vote on 5 questions

mcsmom

  • I post frequently
  • ***
  • Posts: 266
  • Karma: 23
    • Official Joomla! Book
  • CiviCRM version: 4 and 3.4
  • CMS version: Joomla!
Re: Security Issue with Joomla and Profiles - patch 1
July 30, 2009, 10:46:09 pm
This is part of an issue I have been talking about for a while which is that we (and i mean the joomla community + the civi team) really need to work to make a real joomla front end so that things like ACL, SEF and overrides will work. Not only will that let the approriate access checks be built in and pretty urls exist, I think it would be likely to help with some of the problems we have getting Joomla users to actually be able to work with civi.

I have been doing some work on this for a while, which is how we got as far as having view folders. But it would be great to get some other people interested.

In the meantime, I think there could be a check against JMenu::getItem to at least use the menu permissions.

http://api.joomla.org/Joomla-Framework/Application/JMenu.html

rogerco

  • I post occasionally
  • **
  • Posts: 66
  • Karma: 5
Re: Security Issue with Joomla and Profiles - patch 1
August 06, 2009, 02:30:35 am
Hi all,
Firstly apologies to Donald and the team, who I read may have been slightly miffed by my trenchant comments - no disrespect intended at all to the excellent core CiviCRM work, I'm merely interested in making the Joomla+Civi system more usable.  For me, at least, Civi is just one component of a system, and thus far it seems to be missing out on much of the potential of Joomla.

Anyway, whilst away I have been tinkering, and now have some mods which address most (not all) of my concerns and do allow secure (as far as I can tell, so almost certainly not completely secure) access to profile editing facilities on the front end.

Most of what I have done is changes in the joomla frontend component civicrm.php to allow access to profiles (whether menu'ed or direct linked) to be restricted by Joomla user group (guest-registered-author-editor-publisher-manager-admin-superadmin) and/or also by membership of Civi groups.

I did have to make a couple of changes in core files to unpick CRM4668 and replace with user level checks. The access levels are controlled by component and menu parameters, so there are also changes to the joomla xml files and the backend toolbar.

Question now is what is the best way to share these with others for further improvement and validation - please advise, or PM me if you want me to send the install package and more details of the changes.

Incidentally it looks from the complete 2.2.7 install set that there is work in progress to implement a proper MVC front-end component for Joomla - the view files exist but are as far as I can tell not used. This is clearly the right way to go and should be able to implement a front end that is independent of the CRM core, allowing use of the same styles as the rest of one's site.

I think I may have also uncovered a couple of other minor problems - how/where do I go about reporting these?

Regards
RogerCO

PS I don't think the CiviCRM team need do anything more than I have done regarding ACL for Joomla - there is a more sophisticated ACL system for Joomla coming "soon" (poss v1.6? - poss not till v2) and it would be better to wait and use or integrate with the native Joomla ACL rather than have a component which implements its own incompatible ACL system. Hence my preference right now for using the existing Joomla user groups and also making use of CiviCRM's ability to define groups of contacts and use those for access control on the front-end. But then my use of Civi is perhaps unusual in that I never (if possible) expose the backend to ordinary users. Getting front-end access to CiviMember information is my next priority.

Dave Greenberg

  • Administrator
  • I’m (like) Lobo ;)
  • *****
  • Posts: 5760
  • Karma: 226
    • My CiviCRM Blog
Re: Security Issue with Joomla and Profiles - patch 1
August 06, 2009, 03:24:42 pm
Hi Roger - Sounds like you're "on the trail" of some useful improvements. We are open to moving these into core - but timing may be an issue as we are in code freeze on 3.0. Unless the changes to core are quite minor - incorporating them in the core codebase will probably need to wait til 3.0.1 or later.

It would also help us to understand the changes to the work-flow. I'm thinking that your modifications simply give site admins the OPTION to apply access restrictions while creating or editing a menu item. But I'm not clear how this works for "direct access". Some screenshots of the additional UI for setting these permissions would be helpful.

I would recommend creating a new issue on the issue tracker with details on the changes and attached screenshots, and attaching a patch against svn/trunk if possible (or against 2.2.8). The team can then evaluate magnitude / impact of changes and determine a course of action.

As for other "minor problems" you mentioned, if they're recreateable bugs or security holes - best to file issues for each (with patches if possible).

Thx for taking the intiative to make things better!
dave
Protect your investment in CiviCRM by  becoming a Member!

Pages: [1]
  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Developer Discussion (Moderator: Donald Lobo) »
  • Security Issue with Joomla and Profiles - patch 1

This forum was archived on 2017-11-26.