@@ -104,7 +104,7 @@ Ideally developers should do the following.
* For inputs:
***Validate data inputs** as strictly as possible.
* For outputs:
***Validate data outputs** as strictly as possible.
**Also***validate data outputs** as strictly as possible (to provide some redundant protection).
***Encode data outputs** whenever possible (which is most of the time).
* Provide purification for outputs in rare cases when encoding is not possible (e.g. rich text).
...
...
@@ -114,7 +114,7 @@ Ideally developers should do the following.
### CiviCRM's current strategy
Unfortunately (at least as of 2017) CiviCRM exists in a somewhat uncomfortable limbo between the ideal world and the misguided world. In some places, CiviCRM sanitizes inputs with a partial encoding for HTML output, and then does not encode HTML the output. In other places, (e.g. in SQL queries) CiviCRM encodes outputs. In 2012 developers [identified the need to improve this situation](https://issues.civicrm.org/jira/browse/CRM-11532), but unfortunately it's not an easy task because shifting strategies has implications across the entire codebase. This doesn't mean CiviCRM is rife with security vulnerabilities — it just means that CiviCRM has not been *consistent* about how it approaches security.
Unfortunately (at least as of 2017) CiviCRM exists in a somewhat uncomfortable limbo between the ideal world and the misguided world. In some places, CiviCRM sanitizes inputs with a partial encoding for HTML output, and then does not encode the HTML output. In other places, (e.g. in SQL queries) CiviCRM encodes outputs. In 2012, developers [identified the need to improve this situation](https://issues.civicrm.org/jira/browse/CRM-11532), but unfortunately it's not an easy task because shifting strategies has implications across the entire codebase. This doesn't mean CiviCRM is rife with security vulnerabilities — it just means that CiviCRM has not been *consistent* about how it approaches security.
CiviCRM has a number of permissions that are able to be set through the relevant permissions page of your Content Management System. These are the primary way CiviCRM controls what parts of CiviCRM users are able to see. E.g. Accessing the Scheduled Reminders screen in CiviCRM requires the permission of Administer CiviCRM at least. Permissions are also there to control access to various entities such as contacts. There are generally 2 permissions `Access All Contacts` and `Edit All Contacts` These give the users that are granted those permissions the access to See and possibly edit all the contacts metioned.
CiviCRM has a number of permissions that are able to be set through the relevant permissions page of your Content Management System. These are the primary way CiviCRM controls what parts of the application users are able to see. For example, accessing the "Scheduled Reminders" screen in CiviCRM requires the permission of `Administer CiviCRM` at least. Permissions are also there to control access to various entities such as contacts. There are generally 2 permissions `Access All Contacts` and `Edit All Contacts`. Users which have those permissions will be able to see and possibly edit all contacts.
## Key Permissions
As mentioned in the introduction there are some crucial permissions to get heads around
-`Administer CiviCRM` - This is a very broad permisison and generally speaking is designed to grant access to any administrative parts of CiviCRM
-`Edit All Contacts`, `View All Contacts` - This grants access to all contacts within the database for editing purposes
-`Access All Customdata` - This grants the user access to view and edit all the custom data in the system.
-`Access n` - These permissions are for each core module e.g. CiviContribute CiviEvent. Where N will be the title of that module. These permissions grant access to those areas of CiviCRM. These permissions will only show up if the modules are enabled.
*`Administer CiviCRM` - This is a very broad permission and generally speaking is designed to grant access to any administrative parts of CiviCRM
*`Edit All Contacts`, `View All Contacts` - This grants access to all contacts within the database for editing purposes
*`Access All Customdata` - This grants the user access to view and edit all the custom data in the system.
*`Access X` - These permissions are for each core module e.g. CiviContribute CiviEvent. Where `X` will be the title of that module. These permissions grant access to those areas of CiviCRM. These permissions will only show up if the modules are enabled.
## Implementing Permissions logic
When in an extension you create a page or form there will be an XML routing file that will be needed to register your path, within the xml document you can put in a key of `access_arguments` This allows developers to specify what should be the default permissions that are needed to access this url. It should be noted if you want to specify an or contition e.g. Administer CiviCRM or Access CiviEvent you need to put it as ```xml<access_arguments>Administer CiviCRM;Access CiviEvent</access_arguments>```. If you want to do an And i.e. the user needs both permissions you should change the ; for a , in that example.
When in an extension you create a page or form there will be an XML routing file that will be needed to register your path, within the XML document you can put in a key of `access_arguments` This allows developers to specify what should be the default permissions that are needed to access this url. It should be noted if you want to specify an "OR" condition e.g. "Administer CiviCRM *or* Access CiviEvent" you need to put it as `xml<access_arguments>Administer CiviCRM;Access CiviEvent</access_arguments>`. If you want to do an "AND" i.e. the user needs both permissions you should change the ; for a , in that example.
The other form of permissions implementation happens within generally speaking run functions of pages as normally pages have linked to the various forms and the links list is controlled on permissions. The main way this is done is by looking at the function `getIdAndAction` in `CRM\Core\Page\Basic.php` This determines what action e.g. Update, Browse, Delete etc and checks if the user has permission do to that Action.
Permissions are also implemented within `run` functions of pages. Normally pages have permissions associated with the various forms and links. The main way this is done is by looking at the function `getIdAndAction` in `CRM\Core\Page\Basic.php` This determines what action e.g. Update, Browse, Delete etc and checks if the user has permission do to that Action.
Another function that does similar work but is more useful is `CRM_Core_Permission::checkActionPermission` This generally gets used in BAO functions when perparing list of links.
Another function that does similar work but is more useful is `CRM_Core_Permission::checkActionPermission`. This generally gets used in BAO functions when preparing a list of links.
When developers are writing code it is useful to use`CRM_Core_Permission::check` to see if the user holds the required permissions.
When you write code, you can look at`CRM_Core_Permission::check` to see if the user holds the required permissions.
## API Permissions
Depending on how the API is called it is either called with a "check_permissions" flag turned off or turned on. When it is turned off, It will run the API without checking if the user has the necessary permissions to perform the action needed. If you turn check_permissions on then there will be tests done. By default code in CLI tools e.g. drush or WP-cli or within core code or extension code that is done at run time, the default in CiviCRM APIv3 is that the check_permissions flag is turned off. If you call the CiviCRM API through the rest interface then by default the check_permissions flag will be turned on. The permissions need to make various API calls are defined in `CRM_Core_Permission::getEntityActionPermissions()`
Depending on how the API is called, it is either called with a `check_permissions` flag turned off or turned on. When it is turned off, it will run the API without checking if the user has the necessary permissions to perform the action needed. If you turn `check_permissions` on then there will be tests done. By default code in CLI tools e.g. drush or WP-cli or within core code or extension code that is done at run time, the default in CiviCRM APIv3 is that the `check_permissions` flag is turned off. If you call the CiviCRM API through the rest interface then by default the `check_permissions` flag will be turned on. The permissions needed to make various API calls are defined in `CRM_Core_Permission::getEntityActionPermissions()`
## Extending Permissions
If developers want to add a permission to the list in their CMS, developers can implement `hook_civicrm_permission` This allows developers to specifiy new permissions that would then be avaliable to then select within the content management system permissions. See the [hook documentation](/hooks/hook_civicrm_permission/) for more information and example implementation.
If you want to add a permission to the list in the CMS, you can implement [hook_civicrm_permission](/hooks/hook_civicrm_permission/). Here, you can specify new permissions that will then be available to select within the CMS permissions.
## Altering API Permissions
If a developer wants to alter the permissions that are used in the API permissions check to alter what permissions are needed. Developers can implement the `hook_civicrm_alterAPIPermissions` this will alter permissions. See the [hook documentation](/hooks/hook_civicrm_alterAPIPermissions/) for examples. It should be important to note that developers should be very careful when altering any permissions as they may have unintended consequences.
If you want to alter the permissions the API uses during its permissions check, you can implement the [hook_civicrm_alterAPIPermissions](/hooks/hook_civicrm_alterAPIPermissions/). Note that you should be very careful when altering any permissions because they may have unintended consequences.
CiviCRM Core team and the CiviCRM Security Team are responsible for fixing reported security issues within supported CiviCRM versions. Security released will only be made for those versions with active CiviCRM support. Security Advisories will be made avaliable at the same time as the release of the fix version.
## Supported Release Versions
As of August 2017, CiviCRM maintains two supported CiviCRM Versions 4.7.x series and the 4.6.x series. 4.6.x is in Long Term Support with new features and more active development going into the 4.7.x series.
CiviCRM Core Team and Security Team are responsible for fixing reported security issues within [supported CiviCRM versions](https://civicrm.org/download). Security releases will only be made for those versions with active CiviCRM support, at which point [Security Advisories](https://civicrm.org/advisory) will be issued.
## Release Timing.
CiviCRM maintains two Security release windows, they are the first and third Wednesday of every month US/PDT Timezone. Having a release window doesn't mean that a release will occur but it does allow for site administrators to be concious of when there may be a security update.
CiviCRM maintains two security release windows, they are the first and third Wednesday of every month US/PDT Timezone. Having a release window doesn't mean that a release will occur, but it does allow for site administrators to be conscious of when there may be a security update.
## Reporting a Security bug
CiviCRM maitnains an email address `security@civicrm.org` which is at present the primary mechanism for reporting security issues. When you do report an issue please include all possible information that would help the Security Team replicate and help solve the issue. You will be credited with reporting the issue unless you request anonymity and also for any part you take in its resolution.
CiviCRM maintains an email address [security@civicrm.org](mailto:security@civicrm.org) as the primary mechanism for reporting security issues. When you report an issue, please include all possible information that would help the Security Team replicate and help solve the issue. Unless you request anonymity, you will be credited for your role in reporting the issue as well as any other roles you take in resolving it.
## Security Policy
CiviCRM Has a publicly avaliable policy which details these points and goes into some further detail around our Security practices. The policy is avaliable on the [CiviCRM Website](https://civicrm.org/security).
CiviCRM has a publicly available [Security Policy](https://civicrm.org/security) which details these points and goes into some further detail around our security practices.
