csaf-poc / csaf_webview Goto Github PK

A user wants to enter a domain and see if they are already offering CSAF documents.

If a simple backend is offered, (like #38) then adding code to detect the provider-metadata.json (PMD) s on the backend side could be helpful so the app could offer to take domain names.

The backend can utilise the https://github.com/csaf-poc/csaf_distribution code so that PMD detection is only implemented once.

Add favicon and title so the app can be recognised in the browser tabs and bookmarks.

The specification talks about three ways to "load" information into the viewer:

• per drag and drop in the browser - which is currently implemented
• using an URL in a Form - which has to be implemented
• using an URL in form of an anchor ("URI fragment") - which has to be implemented

It might be a good idea having in addition to that the possibility of using a "file dialogue".

If a new view is attempted, and an error occurs, the old info should be deleted.

Current main does not do it, enter e.g.
https://wid.cert-bund.de/.well-known/csaf/white/bsi-wid-white.json
then delete the last "n" and reload, there is error message, but the old contents is still shown.
Should be fixed for all variants.

According to https://developer.mozilla.org/en-US/docs/Web/API/fetch we need to deal with exceptions and with different response codes in case response.ok == false.

Dot get done in lib/urloader.ts

Document

• acknowledgments
• aggregate_severity
• category
• csaf_version
• distribution
• lang
• notes
• publisher
• references
• source_lang
• title
• tracking
  • aliases
  • current_release_date
  • generator
  • id
  • initial release_date
  • revision history
  • status
  • version

Product Tree

• branches
• full_product_names
• product_groups
• relationships

Vulnerabilities

• acknowledgements
• cve
• cwe
• discovery date
• flags
• ids
• involvements
• notes
• product_status
• references
• release_date
• remediations
• scores
• threats
• title

Currently (Commit 51c6e75) the integrationtests are failing.

And they do so for no obvious reason. I opened the application in the browser and the application does well. There are no hidden console errors or an indicator of what is happening.

I watched the recent changes - namely the contribution of @bernhard-herzog which the errors could not be attributed to.

Using npx playwright test --ui I took a look at the first failing test.

test("general collapsible content Revision history", async ({ page }) => {
  await page.goto("/");
  await page.locator('input[type="file"]').click();
  await page.locator('input[type="file"]').setInputFiles("./docs/bsi-2022-0001.json");

  await expect(page.getByRole("heading", { name: " Revision history" })).toBeVisible();
})

Translated to plain english there is nothing more going on than:

• open page
• load file
• look for "Revision history" to appear.

And the result in the headless browser looks like

So the file seems to have been loaded but no rendering of a revision history nor general information took place.

The behavior in the browser looks correct.

For now I am at my wit's end.

Dear contributors,
We would like to change the license from MIT to Apache 2.0 to avoid any patent claims. This includes (but is not limited to) all currently existing code and all future code.

@Intevation: @bernhardreiter

Are you okay with this?

• An error remains if using the back button. Go to https://wid.cert-bund.de/.well-known/csaf/provider-metadata.json press on a GREEN link (without having access) and see the error message. Use "back" in the browser and see error message still is there, as is the text of the PMD.

See

• The "Distribution 1" list should be sorted by URL, so that same urls with different TLP values are belo each other.

• The OpenPGP links shall be hyperlinks.

• (optional) internal link to the same page should be indicated on a low level (we could use a different link color here or an icon)

• (optional) links to a different webview view should be indicated.

To reuse the single CSAF document view of the repository in different javascript frameworks, consider moving to create standard https://developer.mozilla.org/en-US/docs/Web/API/Web_components .

It is possible to do so in Svelte (e.g. https://blog.logrocket.com/build-web-components-svelte/) which is used so far. It would be possible to use (and create) in VueJS3 as well, see https://vuejs.org/guide/extras/web-components.html#using-custom-elements-in-vue

Considerations

• Depending on the use case and which framework is used in a product that shall use the casf document view, the requirements for an integration can be different. A migration to web components can be done much better once the use case and application is known.
• As the build options have to be changed and a file for the import as to be created, a migration to web components will be a little bit of work more for implementation and maintenance of this product. Again it is better to have that additional effort when it is needed, but not earlier.

The use case:
An interested users wants to explore several CSAF Providers quickly.

can easily supported by offering a simple backend that only serves the SPA locally and provides a proxy that can access the CSAF providers.

At first it seemed like the proper thing to do after loading to simply validate the incoming document.
Unfortunately this turned out harder than at first sight.

1. Using the common library of AJV I had discovered that the document specification of the schema has itself a specification of 2012-12 of JSON-Schema. Referenced are schemata like https://www.first.org/cvss/cvss-v2.0.json which is draft-04 or https://www.first.org/cvss/cvss-v3.1.json which is draft-07. Simply combining these schemata didn't work. On top draft-04 is not supported in the current version of ajv.
   I opened a stack overflow question but without results (at the time of writing this 2023-07-05) so far. I even copied the approach from here which resulted in no schema with key or ref "http://json-schema.org/draft-04/schema#"(the gist)

2. I tried to include the csaf-validator-library with their instructions. It turns out that it doesn't seem to work in browser context.

I suggest to postpone the schema validation to a later point in time.

Displaying https://csaf-poc.github.io/csaf_webview/feed?q=https://csaf.data.security.nozominetworks.com/provider-metadata.json

and clicking on "Distribution 1" gives me a crash with 1.0.0 and the following error message in Chromium:

3.57fc9617.js:1 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'feeds')
    at Ot (3.57fc9617.js:1:19527)
    at At (index.7a644faf.js:1:6007)
    at new Nt (3.57fc9617.js:1:19777)
    at Array.Bt (3.57fc9617.js:1:20618)
    at A (scheduler.cc1c0861.js:1:571)
    at dn (Spinner.f025728e.js:1:11991)
    at Object.p (Spinner.f025728e.js:1:13240)
    at z (scheduler.cc1c0861.js:1:1898)
    at M (scheduler.cc1c0861.js:1:1553)
Spinner.f025728e.js:1 Uncaught TypeError: Cannot read properties of null (reading 'getBoundingClientRect')
    at Spinner.f025728e.js:1:13786

Example:

Open https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/OT/white/2024/icsa-24-023-05.json in the viewer.

Expand Vulnerabilities and then Remediations 

Problem:

Despite having only the child collapsible "Category: mitigation", it's not automatically expanded.

Some URLs in the CSAF document are rendered with a-elements so that
they're cliackable. This is problematic for e.g. javascript: URLs
because clicking on them will execute the JavaScript code. The URL
contents are also shown as the text content of the a-element so it's
pretty obvious that the URL might be dangerous, but it would be better
to restrict clickable URLs to reasonably safe protocols like http: and
https:

When opening an url to a document and then switching to rolie feed view and back, the document should still be preserved. Including the collapsible state.

In general it is nice if the last url ist kept, e.g. as part of the url so it could be bookmarked.

A user wants to see what a CSAF lister or mirror has to offer.

Technically this would mean to parse and display an aggregator.json file as well.

Currently there is no user accessible way to tell which version is served as a Github page.
That should be possible.

Commit f968cbe includes now the support for (github flavoured) Markdown.
To test you could modify e.g. the notes of a document like

"notes": [
        {
          "category": "description",
          "text": "**CSAF Tools CVRF-CSAF-Converter 1.0.0-rc1** resolves XML External Entities (XXE). _This_ leads to the inclusion of arbitrary (local) file content into the generated output document. An attacker can exploit this to disclose information from the system running the converter.",
          "title": "Vulnerability description"
        }
      ],

It should render the text properly.

Basically any text could now contain Markdown which would be rendered.

This issue is open to test the behaviour.

User that have any CSAF url, like a provider-metadata.json, a ROLIE feed or a single document can just put it in a field without thinking what it is.

This improves usability be reducing needed thought and a potential click.

Technically the web app has to detect which URL it is.

There should be a representation of the product_tree that can be navigated by the user.

It seems servers in the wild often do not allow a single page application via a web browser by not setting the Access-Control-Allow-Origin: * header.

The header is not yet required by the CSAF 2.0 standard. As it would make sense we've suggest this in oasis-tcs/csaf#653 .

At least the BSI and Redhat did not provide he needed ACAO headers so an application just served via github pages will not be able to load the files from them (neither single documents, nor ROLIE feeds).

So we need a proxy until the CSAF standards and implementations change. In a development setup, this is not a problems, as we can use the serving node.js development server to do the additional proxying work. But this is a high requirement for people that want to use this product.

Do we need
a) a way to deploy this on a single machine, then we could look for a small proxy application to run on localhost
or
b) instruction and software for a public setup, which means a server with CPU bandwidth and protection against abuse for the proxy work ?

E.g. android-chrome-192x192.png does not have a proper license. android-chrome-192x192.png.license is merely a copy of it. This needs to be fixed and there should be an automated way to check for licenses.

CSAF files can be quite complex. We should introduce as much help to the reader as we can. A table should be created to show the results:

Example given for 6 products and 3 vulnerabilities:

Symbols could be:
✔️ fixed
⚠️ under_investigation
✖️ known affected
➖ not affected
💚 recommended

When installing the project dependencies via npm install, there is a warning about 2 vulnerabilities:

2 vulnerabilities (1 moderate, 1 high)

Perhaps this is what we are looking for.
dbc62ed established the gathering of related data.

When trying to view https://wid.cert-bund.de/.well-known/csaf/white/2023/wid-sec-w-2023-2662.json in
v0.6.0 and later nothing is shown and the browser console has:

proxy.js?v=0ea9c63c:15 [HMR][Svelte] Unrecoverable HMR error in <ProductTree>: next update will trigger a full reload

Uncaught (in promise) Error: {#each} only works with iterable values.
    at ensure_array_like_dev (dev.js:218:9)
    at create_fragment (ProductTree.svelte:40:78)
    at init (Component.js:148:34)
    at new ProductTree (ProductTree.svelte:20:7)
    at createProxiedComponent (svelte-hooks.js?v=0ea9c63c:341:9)
    at new ProxyComponent (proxy.js?v=0ea9c63c:242:7)
    at new Proxy<ProductTree> (proxy.js?v=0ea9c63c:349:11)
    at Array.create_default_slot_1 (SingleView.svelte:65:46)
    at create_slot (utils.js:165:22)
    at create_fragment (Collapsible.svelte:62:20)

Since Commit 25409a1 the .env.development file is included. Because there are no secrets contained this should be viable. The proxy configuration in vite.config.ts is defaulted to https://wid.cert-bund.de/. So the developer setup should work ootb with https://wid.cert-bund.de/.well-known/csaf/white/bsi-wid-white.json.

This issue is only open for testing.

The vulnerabilities should be displayed per item. An item is expandable, all can be collapse/expanded at the same time.

The CVE and the highest baseScore/Severity is always displayed.