Wiki source code of XWiki Security Policy

Last modified by Vincent Massol on 2024/02/09 10:24

Hide last authors
Simon Urli 1.2 1 {{box cssClass="floatinginfobox"}}
2 {{toc/}}
3 {{/box}}
4
Simon Urli 1.1 5 The goal of this document is to provide some information about the policy of XWiki.org in case a vulnerability is found in XWiki Standard.
6
Simon Urli 1.2 7 = What are the available channels to discuss about security issues? =
Simon Urli 1.1 8
Simon Urli 2.1 9 Four channels are available with different usages.
Simon Urli 1.1 10
Vincent Massol 24.1 11 These channels are private because we want to apply the following strategy:
12 * Don't make it too easy for hackers to find about security issues before we've had the chance to provide a fix that our users can apply on their XWiki instances.
13 * Once we have fixed a security issue and released XWiki versions with the fix, and after a defined waiting period (see below for more details) to allow users to upgrade, the seecurity issue is disclosed publicly.
14
Vincent Massol 6.1 15 == Security Forum & Mailing-List ==
Simon Urli 1.1 16
Vincent Massol 6.1 17 The main discussion channel is the private [[security forum category >>https://forum.xwiki.org/c/security/16]]. However, this channel is private and for this reason, we've kept the old mailing-list (security[at]xwiki.org) since anyone can post on it (but only core committers and some other trusted persons can read them). See also [[Mailing Lists>>doc:Community.Discuss||anchor="HMailingLists"]].
Simon Urli 1.1 18
Vincent Massol 6.1 19 The forum channel **must be used** for warning the sponsoring companies that a new security issue has been discovered. It **might be used** for asking about a potential security issue.
Simon Urli 1.1 20
Simon Urli 1.2 21 == JIRA ==
Simon Urli 1.1 22
Vincent Massol 10.4 23 The JIRA of XWiki ([[https:~~/~~/jira.xwiki.org>>url:https://jira.xwiki.org]]) is the right place to submit issues by using the level set to Confidential and the ##security## label. Those issues are only visible to people who submitted them, to the committers of XWiki, and to anyone trusted by the XWiki committers who can help fixing them. All informations about the submitted issues if discussed elsewhere should be added on the comments of the issues so that the reporter can follow them. Note that the label “security” could be used in JIRA dashboard or in Release Notes to inform about the fixed security issues.
Simon Urli 1.1 24
Simon Urli 1.2 25 == Matrix ==
Simon Urli 1.1 26
Vincent Massol 24.1 27 A private dedicated Matrix Chat room is dedicated to talk about security issues but is dedicated to the same people as the security mailing-list. It should be mainly used to discuss about the security policy and technical details about a specific issue.
Simon Urli 1.1 28
Vincent Massol 24.1 29 More information is available on the [[Chat page>>doc:Community.Chat||anchor="HMatrix"]].
30
Simon Urli 2.1 31 == Github Security Advisories ==
32
Simon Urli 15.1 33 For each security issue fixed for XWiki, a dedicated security advisory is created on Github. Those advisories remain private until they are publicly disclosed. By default, the owners of a Github organization can view the advisories: in the case of XWiki, the Github organization is owned by all XWiki committers.
Vincent Massol 24.1 34
Simon Urli 2.2 35 On top of that, access to the advisories is also manually granted to a dedicated Github Team for trusted people who are not committers, to see the advisories before they are publicly disclosed.
Simon Urli 2.1 36
37 People wanting to get access to this Github Team should request access on the security mailing-list.
38
Simon Urli 1.2 39 = Where to submit security issues? =
Simon Urli 1.1 40
Vincent Massol 10.4 41 As specified above, all security issues should be submitted on [[https:~~/~~/jira.xwiki.org>>url:https://jira.xwiki.org]] with the level set to Confidential and the ##security## label. Try to give as much information as possible for those issues and in particular a way to exploit the vulnerability, or a way to assess that the vulnerability is present: we will use it to determine if some instances are subject to it or not.
Simon Urli 9.1 42
Simon Urli 1.1 43 Those issues are only visible to people who submitted them, to the committers of XWiki and to anyone trusted by the XWiki committers who could help fixing them.
44
Simon Urli 1.2 45 = What are the criteria for computing severity? =
Simon Urli 1.1 46
47 The severity is defined case by case by the core committers depending on two criteria:
48
49 * the impact of the security issue (e.g. an issue that might impact all pages of a wiki is more severe than an issue which might impact only pages with specific rights)
50 * and the difficulty to reproduce it (e.g. an issue which needs script rights to be reproduced is less severe than an issue which only needs view access on the wiki)
51
52 We currently use two types of labels to compute the severity of an issue: the type of attacker (depending on its rights on the wiki) and the type of attack (depending on what he can actually do).
53
Vincent Massol 12.1 54 {{info}}
55 When adding a new label in JIRA for attackers or attacks, you need to also edit the following 2 filters to add the new labels:
Simon Urli 15.1 56
Vincent Massol 12.1 57 * [[Security issues missing categorization>>https://jira.xwiki.org/issues/?filter=16100]]
58 * [[Open security issues missing categorization>>https://jira.xwiki.org/issues/?filter=16099]]
59 {{/info}}
60
Simon Urli 1.2 61 == Types of attackers ==
Simon Urli 1.1 62
63 |=Label|=Description
64 |attacker_guest|The attacker doesn’t need to be logged-in to perform the attack.
Thomas Mortagne 3.1 65 |attacker_account|The attacker needs to be logged-in to perform the attack.
66 |attacker_view|The attacker needs to have view right to perform the attack.
Simon Urli 1.1 67 |attacker_comment|The attacker needs to be logged-in and the comment rights to perform the attack.
68 |attacker_edit|Same as above but with edit rights.
69 |attacker_script|Same as above but with script rights.
Vincent Massol 12.2 70 |attacker_socialeng|The attacker can only perform the attack if he has physical access to the target device
Simon Urli 1.1 71
Simon Urli 1.2 72 == Types of attacks ==
Simon Urli 1.1 73
74 |=Label|=Description
Vincent Massol 12.2 75 |attack_stability|Attacks that are related to targeting the host (e.g. DOS attack)
76 |attack_escalation|Attacks that are related to permanently getting more rights
77 |attack_login|Attacks that are related to login with another user identity
78 |attack_xss|All attacks related to code injection
79 |attack_impersonation|Attacks that are related to using another people right to perform actions
80 |attack_dataleak|Attacks that are related to confidential data that might be retrieved in readonly: could be emails, but could also be XWiki document that shouldn’t be viewable.
81 |attack_spam|Attacks that are related to spamming
Simon Urli 1.1 82
Simon Urli 16.1 83 == Severity ==
Simon Urli 1.1 84
Simon Urli 16.1 85 The severity of the security tickets should be computed using a CVSS calculator such as [[https:~~/~~/nvd.nist.gov/vuln-metrics/cvss/v3-calculator>>url:https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator]].
86
87 Note that we only use the base metrics right now for computing CVSS in XWiki.
88
89 A proposed severity mapping for our JIRA tickets using the CVSS score is the following:
90
Michael Hamann 19.1 91 * 0.1 - 3.9: Minor
92 * 4.0 - 6.9: Major
93 * 7.0 - 8.9: Critical
94 * 9.0 - 10.0: Blocker
95
Simon Urli 16.1 96 === Best practices for computing CVSS ===
97
98 In general it's good to refer to [[the official documentation>>https://www.first.org/cvss/v3.1/specification-document#Base-Metrics]] for understanding CVSS, and to also look on [[the examples>>https://www.first.org/cvss/v3.1/examples]] to better understand the different criteria.
99 Besides this, some best practices have been established for computing CVSS specifically for XWiki tickets.
100
101 ==== Attack vector ====
102
103 It should always be Network.
104
105 ==== Attack complexity ====
106
107 We don't have a specific best practice for this yet: the official definition and examples should be used to define the value. In case of doubt, best is to discuss with the community.
108
109 ==== Privileges Required ====
110
111 We defined the following mapping to apply the privileges required from CVSS which is a very discretized scope, to the continuum of rights from XWiki:
112
Michael Hamann 19.1 113 * None: Apply for any vulnerability that might be done with Guest user with standard XWiki right, AND with Guest user with Comment right as it’s a supported UC in XWiki which is supposed to prevent giving more rights to Guest
114 * Low: Apply for any vulnerability that might be done with registered users with standard XWiki right (note that it includes Script right for XWiki < 14.10)
115 * High: Apply for any vulnerability that involves more right than the standard XWiki right (can be allowing Script right for XWiki 14.10+, or Delete on the whole wiki, admin on a space etc)
Simon Urli 16.1 116
117 Note that when we refer to standard XWiki right above we mean bundled rights scheme in Xwiki Standard.
118
119 ==== User Interaction ====
120
121 We don't have a specific best practice for this yet: the official definition and examples should be used to define the value. In case of doubt, best is to discuss with the community.
122
123 ==== Scope ====
124
125 We don't have a specific best practice for this yet: the official definition and examples should be used to define the value. In case of doubt, best is to discuss with the community.
126
Michael Hamann 19.1 127 ==== Confidentiality Impact ====
Simon Urli 16.1 128
129 In case of XSS vulnerability the impact should always be set to High.
130
131 For other cases the official definition and examples should be used to define the value. In case of doubt, best is to discuss with the community.
132
133 ==== Integrity Impact ====
134
135 In case of XSS vulnerability the impact should always be set to High.
136
137 For other cases the official definition and examples should be used to define the value. In case of doubt, best is to discuss with the community.
138
139 ==== Availability Impact ====
140
141 In case of XSS vulnerability the impact should always be set to High.
142
143 For other cases the official definition and examples should be used to define the value. In case of doubt, best is to discuss with the community.
144
145 === Deprecated Severity Matrix ===
146
147 {{warning}}
148 The following severity matrix was used for computing the severity of our security tickets, before we started to enforce the usage of CVSS. It's now only provided as an indicative tool to read our old JIRA tickets.
149 {{/warning}}
150
Simon Urli 1.1 151 **DISCLAIMER**: This severity matrix is only indicative, the severity is computed on a case-by-case basis only.
152
153 How to read this matrix:
154
155 * columns are representing the type of attackers
156 * lines are representing the type of attacks
157 * values are a severity between high / medium / low
158
Thomas Mortagne 5.1 159 |=Attacks \ Attackers|=guest|=account or view|=comment|=edit|=script|=socialeng
Simon Urli 1.1 160 |stability|High|High|High|Medium|Medium|Low
161 |escalation|High|High|High|High|Medium|Low
162 |impersonation|High|High|High|High|Medium|Low
163 |login|High|High|High|Medium|Low|Low
164 |xss|High|High|High|Medium|Low|Low
165 |dataleak|High|High|High|Medium|Low|Low
166 |spam|High|High|High|Medium|Low|Low
167
Vincent Massol 11.1 168 Note: in the future we’ll need to formalize the usage of [[https:~~/~~/nvd.nist.gov/vuln-metrics/cvss/v3-calculator>>url:https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator]] to compute the severity of our security.
Simon Urli 1.1 169
Simon Urli 1.2 170 = How long does it take to fix a security issue? =
Simon Urli 1.1 171
Vincent Massol 11.1 172 The priority of the JIRA issue is set depending on the severity of the issue, we apply the following mapping:
Simon Urli 1.1 173
Vincent Massol 11.1 174 * High severity: Blocker in JIRA
175 * Medium severity: Critical in JIRA
176 * Low severity: Major in JIRA
Simon Urli 1.1 177
Vincent Massol 11.1 178 Blocker issues have to be fixed before the next release. There’s no obligations about critical and major issues, so they are handled depending on the other priorities of the core committers.
Simon Urli 1.1 179
Vincent Massol 11.1 180 {{info}}
181 On the 2022-07-07 the use of the JIRA "Development Priority" field was [[stopped>>https://forum.xwiki.org/t/priority-vs-dev-priority-in-jira-for-security-issues/10645]] and only the "Priority" one is used from then on.
182 {{/info}}
183
Simon Urli 1.2 184 = When is a security issue considered as fixed? =
Simon Urli 1.1 185
186 Security issues are considered as fixed only once the fix is part of releases for all supported branches impacted by the issue. So for example, if [[XWiki.org>>url:http://XWiki.org]] is currently in the 12.x cycle and a security issue impacts both 11.10.1 (LTS) and 12.3 (stable), the issue is fixed when 11.10.2 and 12.3.1 (or 12.4) are released with the fix.
187
Simon Urli 1.2 188 = Are security issues ever publicly disclosed? =
Simon Urli 1.1 189
Vincent Massol 14.3 190 Once the issue has been properly fixed and the fix has been released, a CVE is published to publicly disclose about this issue and to incitate for an upgrade. The CVE is **mandatory** for any security issues.
Simon Urli 1.1 191
Simon Urli 1.2 192 = How long does it take to publish a CVE? =
Simon Urli 1.1 193
Simon Urli 14.1 194 Once an issue has been fixed and released, an embargo of at least 3 months is starting to allow anyone working with XWiki to perform actions before the publication of the CVE. The embargo might be longer than 3 months, in which case extending the embargo might be decided through a vote on the forum. The sponsoring companies are automatically informed as soon as a security issues has been discovered through the security communication channels.
Simon Urli 1.1 195
196 For example, if a security issue has been fixed and released in 11.10.2 and in 12.0, respectively released the 5th of February and the 29th of January, the CVE could be published 3 months after latest release: i.e. the 5th of May.
197
Simon Urli 1.2 198 = What’s the process to handle security issues for committers? =
Simon Urli 1.1 199
200 1. Take the ownership on the security issue by assigning the JIRA ticket to yourself.
Vincent Massol 10.1 201 1. Validate the information about the security issue
Vincent Massol 10.2 202 1*. Verify that the Confidential level is set
203 1*. Verify that the security labels are set and are correct
204 1*. Verify that the ##security## label is set (needed for example to know which issues are security issues when the Confidential level is removed)
205 1*. Provide missing information, and, in particular, make sure that the issue contains reproduction steps to either exploit the vulnerability or assess its presence
Simon Urli 2.1 206 1. Fix the issue on all supported branches
Simon Urli 15.1 207 1. Create a draft advisory on Github (see section below).
Manuel Leduc 15.2 208 1. Add a link to the advisory draft on the JIRA issue(s)
209 1. Announce the fix on the security section of the forum with the list of branches where the fix is provided and the link to the advisory
Simon Urli 2.1 210 1. When all XWiki versions where the fix is provided are released, announce on the security list that the 3 months embargo is starting and specify the date when the issue will be made public
Vincent Massol 10.4 211 1. After 3 months, request a CVE through GitHub Advisory page. Remove the Confidential level on the Jira issue. Publish the advisory once the CVE ID has been received.
Simon Urli 15.1 212
Vincent Massol 21.1 213 = Vulnerabilities in XWiki Dependencies =
Manuel Leduc 17.1 214
Manuel Leduc 17.2 215 In addition to vulnerabilities directly related to the code of XWiki itself, some vulnerabilities can be introduced through the dependencies of XWiki and the extensions installed on it.
Manuel Leduc 17.1 216
Vincent Massol 21.1 217 {{version since="15.5RC1"}}
218 We provide a [[dashboard>>doc:extensions:Extension.Extension.Security.UI.WebHome]] in the Administration that allows you to check if a known vulnerability is present in a wiki.
219
220 {{warning}}
221 At the moment, you need to manually install this extension. Also it's a work in progress and still very experimental. We also need to define a process to decide how to handle when known dependency vulnerabilities are discovered. A first step has been done in that, our CI will fail if there are vulnerabilities detected, preventing us from releasing a new version of XWiki and thus forcing us to address the vulnerabilities in some way.
222 {{/warning}}
223 {{/version}}
224
Manuel Leduc 17.2 225 == How to react if a vulnerability is found in a library or extension? ==
Manuel Leduc 17.1 226
227 In most cases, it's possible to update the extension that contains a vulnerability. In a few cases, it's not possible to upgrade, but the vulnerable dependency has been analyzed and is not considered to directly affect the wiki: in such a case, the vulnerability is marked as analyzed, and the conclusions of the analysis are presented in the dashboard. Finally, if a vulnerability concerns a part that can't be updated because there is no new version and no analysis, you can contact us through the channels defined above.
228
Manuel Leduc 22.1 229 === For committers ===
230
231 When a new CVE is found in the CI, or raised by a user, follow those steps:
Simon Urli 23.1 232
Manuel Leduc 22.1 233 1. analyse the CVE
234 2. see if an upgrade is possible and in this case release of new version of the impacted extensions
Simon Urli 23.1 235 3. add a [[review>>extensions:Extension.Extension.Security.Code.Reviews]] so that users of the dashboard are informed of our analysis, see [[the documentation>>extensions:Extension.Extension.Security.Index.WebHome||anchor="HReviews"]] for more details about the expected format
Manuel Leduc 22.1 236
Manuel Leduc 17.1 237 == How long does it take to fix a vulnerable dependency? ==
238
Michael Hamann 19.1 239 First, a new version with a security fix must be available, and for that we depend on the third-party maintainers. Additionally, if it happens that an upgrade is not possible due to some technical limitations, we can implement a security fix within XWiki to make the issue non-exploitable (also note that many CVEs provide ways to mitigate the identified vulnerability), following our [[security fix policy>>||anchor="HHowlongdoesittaketofixasecurityissue3F"]].
Manuel Leduc 17.1 240
Vincent Massol 18.1 241 = Security Advisory template and information =
Simon Urli 15.1 242
243 For global information of creating a Github advisory, you can consult the official documentation: [[https:~~/~~/docs.github.com/en/code-security/security-advisories/repository-security-advisories/creating-a-repository-security-advisory>>https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/creating-a-repository-security-advisory]].
244
245 You can find below a template to use for the content of a new security advisory:
246
247 {{code language="markdown"}}
248 ### Impact
249
250 Describe here the impact of the vulnerability and provide information about the versions of XWiki impacted by it.
251
252 ### Patches
253
254 Provide in the section the list of patched versions of XWiki. You can also provide some details about the patches.
255
256 ### Workarounds
257
258 Provide information how to workaround the vulnerability when it's possible. If not possible, inform that users should upgrade to get the fix.
259
260 ### References
261
262 You should list here the JIRA ticket(s) related to this vulnerability and when possible the commit that patches it, especially if that's a single one.
263 Don't hesitate to provide more pointers when they make sense.
264
265 ### For more information
266
267 If you have any questions or comments about this advisory:
268 * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)
269 * Email us at [Security Mailing List](mailto:[email protected])
270
271 ### Attribution
272
273 You can specify here who reported the issue.
274 {{/code}}
275
276 The versions set in the security advisory should follow the best practices documented in [[https:~~/~~/docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/best-practices-for-writing-repository-security-advisories#affected-versions>>https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/best-practices-for-writing-repository-security-advisories#affected-versions]]. Then don't forget to pay attention to the format of the version (e.g. 14.10RC1 is not a right version: you should use 14.10-rc-1).
277
278 The severity of the vulnerability should be assessed using CVSS, you can find information and a calculator here to help you: [[https:~~/~~/www.first.org/cvss/v3-1/>>https://www.first.org/cvss/v3-1/]]. You should also try to find a CWE corresponding to the vulnerability. You can browse and search for the closest one using the official website: [[https:~~/~~/cwe.mitre.org/data/index.html>>https://cwe.mitre.org/data/index.html]].
279
280 Finally you should not forget to add "XWiki/Security" Github Team as collaborator of your advisory to ensure proper people are able to see it.
281
Vincent Massol 18.1 282 = Adding a new security member =
283
Vincent Massol 25.1 284 Anyone can ask to get permissions to participate to XWiki Security topics by being added to the channels mentioned above (JIRA issues, Security chat, GitHub advisories, etc). The process is the following:
285 * You need to ask for permission by posting on the [[xwiki.org forum>>https://forum.xwiki.org/]] (in the ##Other## category) and explain why you need access.
286 * XWiki Committers will analyze your request and decide whether you will get access or not. The idea is to do a quick due diligence to check that the request is legit and that the person asking is known and is not going to use the private information for malicious purposes
287 * You'll then be asked on the forum to agree that you won't publicly disclose the non-public security information before the XWiki committers make it public, and that you agree to follow the rules defined in this security policy.
288 * You'll then get invited to all the private security channels.
Vincent Massol 18.1 289
290 Here's the checklist to add a new security member:
Michael Hamann 19.1 291
Vincent Massol 18.1 292 * Add the user to the JIRA ##security## group (to be able to see existing security issues)
293 * Add the user to the Matrix ###xwiki-security## chat (to be able to discuss security issues)
294 * Add the user to the GitHub ##Security## team (to be able to view non-published security advisories)
Michael Hamann 19.1 295 * Add the user to the ##XWikiSecurityGroup## on [[xwiki.org>>xwiki:Main.WebHome]] (to be able to see the [[xwiki:SecurityAdvisoryApplication.WebHome]])
Vincent Massol 20.1 296 * [[Add the user to the ##security## group>>https://forum.xwiki.org/g/security]] on the [[Forum>>https://forum.xwiki.org]].
Vincent Massol 18.1 297 * (optional) Add the user to the ##xwiki-security## mailing list (to be able to see mails about security issues reported by the community)

Get Connected