Display security issues directly inside XWiki Standard

Development
#1

Hi devs,

In an effort for our users to be safe and thus upgrade to XS version that fix security issues, I’d like to propose the idea of developing an extension bundled in XS that would display somewhere (to be defined, see below for options) the list of security issues that exist for the current wiki.

The list would be computed using:

  • The list of published advisories on GitHub (using GH’s REST API). See Repository security advisories - GitHub Docs
  • The current wiki version. Note that even if the wiki has been patched to fix/work around a given security issue, it’ll still be listed since the wiki version will not have changed.

Some options/things to consider:

  • Only list security issues having a CVSS > some value. For example 9 which represents critical issues. Optional: this score could be configurable.
  • Where to display the warning
    • Option 1: As a after header UIX on all pages when the logged in user has Admin rights
    • Option 2: By introducing a new UIXP in the Admin UI (or revisiting the Admin UI home page which could be improved as it currently displays some icons, listing the same options as the vertical menu on the left).
  • We’ll need to ensure that advisories use some syntax when defining the affected XWiki version since we’ll need to parse this field. Example of returned value: "vulnerable_version_range": ">= 1.0.0, < 1.0.1"

WDYT?

Thanks

PS: FTR initially I was suggesting to include security disclosures as part of our What’s New feature, but after discussing with @MichaelHamann , I’ve agreed with him that displaying the list of advisories that applies to the current wiki is a better alternative.

Dashboard for Security issues inside XWiki Standard
Roadmap for XWiki 15.5
#2

+1 with the general idea

Frankly I’m really not sure it would be needed or we’d really want it: even a security issue with a low score should be displayed IMO.

I’d be -1 for this option: it’s going to be a nightmare for Admins and they’ll start to find ways to systematically hide them. So for me it’s deserving the purpose.

-0 for the UIXP, I slightly prefer the idea of improving the UI home page.

I’d suggest an option 3: reusing the UIXP we have in the notification area (currently used for the license expiration for example) to display the number of advisories with a link, and having a new dedicated section in the Administration to display the details.

AFAIK we’re already using the best practices defined by Github for specifying the XWiki version, it’s even documented to use that on XWiki Security Policy - XWiki

#3

Sounds like a good idea to use the Alarm menu

If we list them all then we should also list their CVSS scores and use a LiveTable that can be filtered. You mentioned having an Admin UI section for Advisories. That sounds good and we could have the LT there.

#4

+1 for the general idea

I’m wondering if it’s really the right source. We are using GitHub more as an intermediary to publish CVE, but there are more generic references, like NIST (but seems there are many more from a quick google search). For example, with the NIST API you can use https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=cpe:2.3:a:xwiki:xwiki:12.6.6 to get all CVE affecting XWiki version 12.6.6.
That being said, I find a bit surprising that github seems to have reduced the package information we indicate in Arbitrary filesystem write access from velocity. · Advisory · xwiki/xwiki-commons · GitHub for example to just the product id “xwiki:xwiki” in the published CVE in NVD - CVE-2022-24897.

I think we need both a dashboard in the admin (the reference) and a warning in the header (that would lead to the admin dashboard if you want more details).

I don’t think this is needed if you use the right API (see the example I indicated above where all you have to do is indicate the specific version you want to check, and it will resolve all the CVEs for you, the GitHub API probably also have the same helper).

#5

Yes, I suggested the GitHub API as it seemed complete and nice but since there seems to exist a CVE REST API providing the same info, I agree that it’s a better source.

On the source topic, we might want to offer a REST API redirection on e.x.o if we want to make it easier for the XWiki installs at large (so that they don’t need to whitelist another domain - they’re likely to already have the e.x.o domain whitelisted). OTOH, this means more traffic to e.x.o which isn’t that great.

Thanks

#6

Yeah… I’m not a big fan of this. I think using an API which is a reasonable industry standard is good enough, it’s not like the instance was going to be completely broken if the API does not exist anymore, you just don’t get new advisories anymore (but honestly if you have an XWiki instance old enough for that, you probably have enough advisories already…).

#7

+1 for the general idea as well
-1 for Option 1
-1 for Option 2
+1 for Option 3 (for the same reasons as Simon)

+1

#8

My point was not about the URL being an API that would be broken in the future but rather that several companies only allow some whitelisted domains to be accessible by their apps (XWiki in this case).

But I mostly listed this to be complete as I also agree that they won’t see the advisories but OTOH no main feature of XWiki will broken. They’ll either need to whitelist https://services.nvd.nist.gov/* or use another way to find out what security issues are impacting them.

We’ll just need to handle this gracefully and provide a way to disable this feature.

#9

+1 for this.

#10

There’s just one issue I can see with using Alerts (XWiki.org) : we need the red bubble to increase the value to indicate that there are new alerts. ATM the alert bubble is only controlled by notifications I think. In any case, it makes sense to me that any UIX would be able to add/remove alert items to the bubble.

#11

@mflorea could probably confirm but AFAIR in case of outdated license there’s a visual hint with the background of the bell. We can probably do the same.

#12

Yes. When a font icon is used for the bell we simply change the text color. When an image is used we add some padding around the image and change the background color. See application-licensing/LicensesNotificationsUIX.xml at master · xwikisas/application-licensing · GitHub .

#13

I have started a design page for this feature.
Let me know if I’ve missed some use cases.
Thanks

#14

I’m wondering if it wouldn’t be interesting to collect the vulnerability data on XWiki.org as part of the extension repository if they shall be displayed for every installed extension. The data could then be downloaded by every XWiki instance as part of the extension metadata that is downloaded, anyways. That way, the vulnerability data could also be easily displayed on every extension page on XWiki.org. Further, it would be easier to improve this in the future, e.g., for changes how extension names are reflected in the CVE database (as this is primarily relevant for not-updated installations, we cannot count on the XWiki instance being updated).

#15

We discussed it a bit in a meeting with @tmortagne @vmassol and @mleduc.
There’s two dimensions about that questions.

First, we don’t store in extensions.xwiki.org all the actual things that are installed on a wiki. You could just decide to install a jar on your wiki, and it will be available in the installed extensions. So getting the vulnerabilities from exo won’t be enough, unless we want to mirror a CVE repository.

Now, for the extensions that are on exo we should be able in the future to provide information about known vulnerabilities. But that’s another work than the current one to display in XS the vulnerabilities of installed extensions.

1 Like