Overview
- The users that identify security issues that affect one or multiple XWiki Pro Extensions have two options:
- If they have a GitHub account then they should:
- Identify the GitHub repository holding the source code of the affected XWiki Pro Extension. The source repository is linked from the corresponding documentation page on XWiki Store.
- Follow GitHub's guide on privately reporting a security vulnerability.
- If they don't have a GitHub account then they should write an email to security-proapps@xwiki.com with the following information:
- description of the issue
- steps to reproduce
- XWiki version and environment
- application(s) version
- If they have a GitHub account then they should:
- The XWiki Pro Apps team works on reproducing the issue in maximum 5 business days. If the issue is not reproduced as described, the Pro Apps developers may reach out to the reporter in order to request additional information.
- After the issue is reproduced, the Pro Apps developers open a draft (private) GitHub Advisory, in the repository of the affected application. If requested, the reporter is added to the private GitHub Advisory as a contributor in order to be able to follow the evolution of the issue. The developers describe the issue and assess the severity according to the severity matrix.
- The Pro Apps developers work on fixing the reported security issue.
- After the issue is fixed, the Pro Apps team releases a new version of the application. In the release notes "security fixes" will be mentioned, but no further details will be offered, in order to prevent ill-intended exploitation of the respective problem.
- Three months after the security issue has been fixed and released, the CVE is made public.
Where are security issues reported?
Anyone can report a Pro Apps security issue or concern:
- either by following GitHub's guide on privately reporting a security vulnerability from the GitHub repository holding the source code of the affected extension
- or by writing to security-proapps@xwiki.com, providing all the information required to reproduce the issue
Access to the created security advisories is manually granted to a dedicated Github Team for trusted people such as reporters of the issues, to follow the advisories before they are publicly disclosed.
What are the criteria for computing severity?
The severity is defined case by case by the Pro Apps developers depending on two criteria:
- the impact of the security issue (e.g. an issue that might impact all pages of a wiki is more severe than an issue that might impact only pages with specific rights)
- and the difficulty to reproduce it (e.g. an issue which needs script rights to be reproduced is less severe than an issue that only needs view access on the wiki)
The Pro Apps developer will set the severity on the GitHub advisory.
Types of attackers
| Label | Description |
|---|---|
| attacker_guest | The attacker doesn’t need to be logged in to perform the attack. |
| attacker_account | The attacker needs to be logged in to perform the attack. |
| attacker_view | The attacker needs to have a view right to perform the attack. |
| attacker_comment | The attacker needs to be logged in and have the comment rights to perform the attack. |
| attacker_edit | Same as above but with edit rights. |
| attacker_script | Same as above but with script rights. |
| attacker_socialeng | The attacker can only perform the attack if they have physical access to the target device |
Types of attacks
| Label | Description |
|---|---|
| attack_stability | Attacks that are related to targeting the host (e.g. DOS attack) |
| attack_escalation | Attacks that are related to permanently getting more rights |
| attack_login | Attacks that are related to login with another user identity |
| attack_xss | All attacks related to code injection |
| attack_impersonation | Attacks that are related to using another person's right to perform actions |
| attack_dataleak | Attacks that are related to confidential data that might be retrieved in read-only: could be emails, but could also be XWiki documents that shouldn’t be viewable. |
| attack_spam | Attacks that are related to spamming |
Severity matrix
DISCLAIMER: This severity matrix is only indicative, the severity is computed on a case-by-case basis only.
How to read this matrix:
- columns are representing the type of attackers
- lines are representing the type of attacks
- values are a severity between high / medium / low
| Attacks \ Attackers | guest | account or view | comment | edit | script | socialeng |
|---|---|---|---|---|---|---|
| stability | High | High | High | Medium | Medium | Low |
| escalation | High | High | High | High | Medium | Low |
| impersonation | High | High | High | High | Medium | Low |
| login | High | High | High | Medium | Low | Low |
| xss | High | High | High | Medium | Low | Low |
| data leak | High | High | High | Medium | Low | Low |
| spam | High | High | High | Medium | Low | Low |
How long does it take to fix a security issue?
After a security issue is submitted via email, the Pro Apps developers will test and try to reproduce the issue in maximum 5 business days. If the issue can not be reproduced, they will get back to the reporter to ask for more information.
Once the issue is reproduced, the Pro Apps developers will open a draft GitHub advisory and work on fixing the issue. The resolution will be included in the next release of the application.
When is a security issue considered fixed?
A security issue on Pro Applications is considered fixed once a new version of the application, which includes the security issue resolution, is released.
Are security issues ever publicly disclosed?
Three months after the issue has been properly fixed and the fix released, a CVE is published to disclose this issue. The CVE is mandatory for any security issues.
How long does it take to publish a CVE?
Once an issue has been fixed and released, an embargo of 3 months is starting to allow anyone working with XWiki to perform actions before the publication of the CVE. The Pro Apps customers are automatically informed as soon as a security issue has been discovered through email.
Proactive security checks
XWiki SAS performs periodical security checks on the core product and extensions, including the Pro Applications. If a vulnerability is found, it is reported following the XWiki core process or the Pro Apps process, depending on the affected component.
What’s the process to handle security issues for reporters?
If an user of an XWiki Pro Extension identifies a security issue the following process is to be followed:
- If you have a GitHub account then you should follow GitHub's guide on privately reporting a security vulnerability from the GitHub repository holding the source code of the affected XWiki Pro extension. The link to the source code repository can be found on the documentation page of each extension published on XWiki Store. Otherwise, you need to write an email to security-proapps@xwiki.com with the following information:
- description of the vulnerability
- steps to reproduce the issue
- version of the application where the issue is observed
- version of XWiki where the issue is observed
- environment in which the XWiki instance is installed on (servlet container, database, web browser, os)
- your GitHub account, if you would like to be added on the draft advisory and participate in or follow the work on the issue
- The Pro Apps developers will respond via email with the confirmation of the reproduction of the issue or in order to ask for more details. If more details are needed please provide them at your earliest availability.
- Once the fix is provided in the new version of the application upgrade the extension.
What’s the process to handle security issues for developers?
- Provide missing information, and, in particular, make sure that the advisory contains reproduction steps to either exploit the vulnerability or assess its presence
- Fix the problem. Being a security problem, it would be best to ask for reviews. This can be done by using a PR, without disclosing the purpose from it's title / description, or by using a temporary private fork, created from within the advisory
- Make sure to backport the fix to other supported branches, if these exist
- Release a new version with the fix ASAP, to make sure that users can have this fixed soon
- Update the advisory
- Add the patched version
- Specify the date when it will be made public, which is 3 months after the fix version was released
- After the 3 months have passed, use the `Request CVE` option from the advisory and wait for Github to issue a CVE
- After CVE has been issued, publish the advisory
- Announce the support team to let clients know about the security fix