Display security issues directly inside XWiki Standard

[MichaelHamann]

@vmassol

Active installs are anonymous.

As far as I can see, we store the instance id so they aren’t really anonymous as, e.g., paid app licenses from XWiki SAS also use this instance id to associate a license to an instance. Also, do we make sure not to log the IP address? Otherwise, with time correlation, it should be relatively easy to associate a log entry with an entry in the active installs data and thus obtaining the instance’s IP, which in many cases should be enough to access the instance if it is public.

[vmassol]

@MichaelHamann

As far as I can see, we store the instance id so they aren’t really anonymous as, e.g., paid app licenses from XWiki SAS also use this instance id to associate a license to an instance.

An admin can know his instance id, yes but it’s anonymous for the rest of the world since you’re not supposed to be able to find what XWiki instance when you see an instance id from Active Installs.

If some extension makes the instance id visible to people who are not supposed to see it, then yes, these persons could query active installs data to find out versions of XWiki and Extensions. These extensions need to be fixed.

@MichaelHamann

Also, do we make sure not to log the IP address?

Yes. See also https://extensions.xwiki.org/xwiki/bin/view/Extension/Active%20Installs%20Client%20API which mentions that we don’t store IPs.

[mleduc]

@caubin

To be clear about what I said here : today, we have XWiki instances that run without relying on any third-party service that is not managed by the XWiki community, with the exception of the YouTube video on the home page (which can be easily removed).

Adding a dependency on an external service run by a third party would break this self-sufficiency. On the contrary to the YouTube embed on the home page, it may not be very easy for a careless administrator to know that XWiki will communicate with a third-party server. One option to make it clear that XWiki will be communicating with a third party would be to add an extra step in the main wiki distribution wizard that asks for the admin consent.

Thanks for the input

• IT departments concerned with security should already have their own ways of monitoring security issues for the product they use in production (i.e. they may not need this dashboard).
• The extension will be installed as optional, and if someone thinks the feature is harmful, they will be able to uninstall the extension.
• We’ll introduce a configuration to disable CVEs polling.
• We could introduce a configuration to change the URL used to retrieve the CVEs. This way admins could point to a proxy provided by a trusted third party (e.g. XWiki SAS) which would act as a way to hide the actual instance. WDTY?
• In addition, this proposal is about the default source of CVEs. But I’ll make it possible to configure the hint for the component responsible for checking the results, so that alternatives can be provided.
• The admin approval step is interesting, but a bit challenging in terms of UI/workflow. I’ll think about it.

[surli]

@caubin

The mirroring option that @surli quickly mentioned would be the easiest, provided that we deploy it on one of the existing domains that we currently whitelist (for example https://extensions.xwiki.org/cve/).

Note that this mirroring would be probably a huge work of maintenance put on xwiki.org. I haven’t investigated much yet on this but I wouldn’t push for it as a first solution.

[ludovic]

Hi, I agree with @caubin that we should not call external servers, which could change APIs or disappear or even be blocked. I’m not fan of a proxy either as it seems to be useless to call dozens of time for the same data.

If the goal is to display recent CVEs, I’m not sure how this is a huge maintenance work on xwiki.org. We would just need to update a JSON file with the data that we want to push to instances and then allow instances to get this JSON file. And it could even be a static file for performance (unless we want to be able to filter by version and then it might be a file per version).
In order to reduce the workload, wouldn’t it be interesting to provide that JSON file as part of Active Installs response ? This would avoid a second request.
Now if people deactivate active install, they might still be interested in getting the JSON file. It could be a separate request.

Another aspect is that companies that are very interested in security might also block server side request. Could it be interesting to provide an alternate approach in the Admin by allowing people to click on a link on xwiki.org which displays the content of the CVEs (based on the XWiki Core version passed in parameter) ?

Last aspect, just to be sure. We are not planning to display these CVEs to normal users ? Only admin right ? It should also be fairly easy to deactivate the service.

[vmassol]

@ludovic

In order to reduce the workload, wouldn’t it be interesting to provide that JSON file as part of Active Installs response ? This would avoid a second request.
Now if people deactivate active install, they might still be interested in getting the JSON file. It could be a separate request.

I wouldn’t do this. These are 2 separate features.

@ludovic

Could it be interesting to provide an alternate approach in the Admin by allowing people to click on a link on xwiki.org which displays the content of the CVEs (based on the XWiki Core version passed in parameter) ?

That could be an interesting fallback when the list of CVEs cannot be downloaded in XS (we said we’d display some nice UI when this happens showing an error, with the last date of the updated data). But we would need to transfer the whole list of installed extensions along with their versions, which is not something that wiki owners may wish to share…

@ludovic

Last aspect, just to be sure. We are not planning to display these CVEs to normal users ? Only admin right ? It should also be fairly easy to deactivate the service.

Yes. See also https://design.xwiki.org/xwiki/bin/view/Proposal/ListSecurityIssuesInsideXS

Thanks

[vmassol]

First version implemented in Loading...