[⭐] CSAF Standard

[wurstbrot]

Description

CSAF, or Common Security Advisory Framework, is a standardized format for documenting and sharing security advisories and vulnerabilities in an automated way. It provides a structured approach to convey crucial information about security issues, including their severity, impact, and recommended mitigation steps for a vendor's product. A vendor can also be an open-source project.

Challenge Description

Title: The new challenge Inform the shop about a remediation option for the known vulnerability CVE-2020-15084
Description: The Juice Shop is vulnerable to a known vulnerability in a library, and an advisory has been provided that the Juice Shop is known affected. A fix has not yet appeared. Ask the Juice Shop, including the CVE, when it will be mitigated.

A second advisory will be given about a fixed vulnerability to avoid making it too easy.

Expected difficulty

✔️ / ❌	Difficulty
❌	⭐
✔️	⭐⭐
❔	⭐⭐⭐
❌	⭐⭐⭐⭐
❌	⭐⭐⭐⭐⭐
❌	⭐⭐⭐⭐⭐⭐

Possible attack flow

• Go to the FTP folder http://localhost:3000/ftp/
• Identify that CSAF-2020-15084.json.bak and CSAF-XXX-XXX.json.bak are advisories
• Download both files with null byte injection
• Open both files and identify the known affected status in CSAF-2020-15084.json.bak
• Post a text like "Juice Shop is known to be affected by CVE-2020-15084, when will the patch be applied?"

In the Juice Shop submission, the submission will be tested to contain CVE-2020-15084 and one of the following keywords:

• mitigate
• fix
• patch
  to confirm the challenge has been performed. This will also match other words like "patched".

CSAF Document

I recommend using the product id owasp-juice-shop for the document.

I am trying to find out how to link an SBOM within a container, as it looks like as if it was not documented

[bkimminich]

Nice one! 🚀

The only thing that feels a bit odd is checking for some very generic words plus the CVE# that is already the filename visible in the FTP directory listing. Couldn't we instead write the challenge instructions so that the GitHub security advisory (GHSA#) should be posted? That requires opening the link or the actual file, no?

Also, I don't think .json.bak is needed as a suffix, just .json should be fine as this is not meant to be an accidental backup file.

What do you think?

[wurstbrot]

GitHub currently does not offer advisories that are compliant to the CSAF standard, as discussed in this issue. However, tools like Trivy do support CSAF.

Github security advisories are too generic as they do not provide the information from the vendor. By taking a look at GHSA, a developers/user can not identify if Juice Shop is affected. CSAF offers that the vendors provides the security information. I wouldn't mix GHSA and CSAF because it might cause confusion.

I suggest the following improvements based on your input.

Title: Inform the Juice Shop About an Old Advisory
Description for the scoreboard: The Juice Shop is susceptible to a known vulnerability in a library, for which an advisory has already been issued, marking the Juice Shop as known affected. A fix is still pending. Please inquire with the Juice Shop, including the CSAF Tracking ID, about when a mitigation will be implemented.

We can enable access to the advisories as a CSAF "trusted provider."

New Attack Flow:

• Navigate to /security.txt.
• Use the CSAF attribute to locate /ftp/provider-metadata.json (easier to find also without /security.txt) OR /.well-known/csaf/provider-metadata.json (recommended by CSAF but harder to find).
• Download /.well-known/csaf/provider-metadata.json.
• Review the content, for example:

  {
    "canonical_url": "https://<host>/.well-known/csaf/provider-metadata.json",
    "distributions": [
      {
        "rolie": {
          "feeds": [
            {
              "summary": "All TLP:WHITE advisories of OWASP Juice Shop.",
              "tlp_label": "WHITE",
              "url": "<ORIGIN>/.well-known/csaf/feed-tlp-white.json"
            }
          ]
        }
      }
    ],
    "last_updated": "2024-02-30T20:20:56.169Z",
    "list_on_CSAF_aggregators": false,
    "metadata_version": "2.0",
    "mirror_on_CSAF_aggregators": false,
    "public_openpgp_keys": [
      {
        "fingerprint": "XXX",
        "url": "https://XXX"
      }
    ],
    "publisher": {
      "category": "vendor",
      "name": "OWASP Juice Shop",
      "namespace": "/juice-shop/juice-shop"
    },
    "role": "csaf_trusted_provider"
  }

• Identify that advisories are stored in location /.well-known/csaf/ (e.g. because you know the standard or taking a look into the ROLIE document)
• Follow the navigation (e.g. via /.well-known/csaf/index.txt and identify that /.well-known/csaf/2020/juice-shop-sa-20200513-express-jwt.json and /.well-known/csaf/2020/juice-shop-sa-20200612-XXX.json are advisory documents
• Download both files
• Pretty print both files content (e.g. with jq) because white spaces are removed within the files
• Identify the known affected status in juice-shop-sa-20200513-express-jwt.json and the tracking id juice-shop-sa-20200513-express-jwt
• Post a text like "Juice Shop is known to be affected by CVE-2020-15084, when will the patch be applied as described in CSAF juice-shop-sa-20200513-express-jwt?"

The Juice Shop will test if the submission contains juice-shop-sa-20200513-express-jwt.

Hashes/Signatures for the CSAF documents will be provided as well to be a "trusted provider".

From CSAF documentation:

If this field indicates a web URI, then it MUST begin with https:// (as per section 2.7.2 of [RFC7230]).

As the Juice Shop is often started locally with HTTP, we will violate the specification here. To make it configurable to the user, we could generate the /security.txt with a URL from a configuration value (like in the CSAF provider tool) or based on hostname with scheme HTTPS.
The ROLIE URL in provider-metadata.json should also be generated.

In the CSAF document, we will add an acknowledgement summary, that Juice Shop and the CSAF files are used for security training. Furthermore, that the Juice Shop shouldn't be deployed to production environments.

Difficulty (depends slightly on where we put the CSAF files):

✔️ / ❌	Difficulty
❌	⭐
❌	⭐⭐
✔️	⭐⭐⭐
❌	⭐⭐⭐⭐
❌	⭐⭐⭐⭐⭐
❌	⭐⭐⭐⭐⭐⭐

[bkimminich]

I like the idea of having this whole challenge play out in the .well-known/ folder instead of having any part of it in ftp/, The FTP folder is already used for so much, and having to find the security.txt first (or having a scanner that looks for CSAF-files) is a nice touch. Do we need to bump this to ⭐⭐⭐⭐ then, or is ⭐⭐⭐ still okay? (I lean towards ⭐⭐⭐, but please pick what you think makes more sense.)

[wurstbrot]

⭐⭐⭐ as long as CSAF is mentioned in the description. Afterwards, it is just a look into the specification.

[santosomar]

This is amazing! Thank you @wurstbrot @bkimminich !

I really love the suggestion of having the user/player/student having to find the .well-known/security.txt . Then the user can go to .well-known/csaf/provider-metadata.json and obtain the information about security advisories. This is an example from Siemens and this is another from Cisco.

I think that ⭐⭐⭐ should be fine.

An additional option could be for the user to verify the advisory using the SHA checksum json.sha512 and/or json.asc.

[wurstbrot]

@santosomar
Do you see a way to check that a Juice Shop user has performed the validation?

Thank you for the examples, I tried to find some but failed so far.

For implementation purpose, the directory distribution feels easier than the ROLIE one.

[bkimminich]

@santosomar
Do you see a way to check that a Juice Shop user has performed the validation?

We could ask for the checksum (in)directly in the challenge description and check if it's submitted with the feedback to report the problem, like "Submit a suitable checksum as proof that you did your due diligence."

[wurstbrot]

An other submission sounds a bit boring. In addition, to describe what the user needs to do in order to submit the hash shows a part of the solution.

What about a code challenge with wrong/correct commands to verify?
The base to compare the "potential commandline fixes" with has a wrong command.

Offline @bkimminich and I agreed that a coding challenge suites best for the verify step recommend by @santosomar .

[wurstbrot]

@santosomar
I couldn't find a documentation about the amount of keys for provider-metadata.json. Is it possible to have multiple, e.g. for rolling keys with a period in which both are allowed? Example:

  "public_openpgp_keys": [
    {
      "fingerprint": "19c01cb7157e4645e9e2c863062a85a8cbfbdcda",
      "url": "https://keybase.io/bkimminich/pgp_keys.asc?fingerprint=19c01cb7157e4645e9e2c863062a85a8cbfbdcda"
    },
    {
      "fingerprint": "2372B2B12AEA7AE3001BB3FBD08FB16E2029D870",
      "url": "https://keybase.io/wurstbrot/pgp_keys.asc"
    }
  ],

There is only once place in documentation mentioning public_openpgp_keys. public_openpgp_keys is an array.

Update:
Could answer by myself. Your Siemens example uses multiple keys.

[santosomar]

Sorry for the delay. Yes indeed. You could have multiple keys as you saw in the Siemens example. This is also good feedback to the CSAF TC to include in our faq and guidance documents.

[wurstbrot]

@santosomar I created an issue.

Siemens as well as Cisco are stating to be a csaf_provider. Why not a csaf_trusted_provider?

[santosomar]

Thank you so much for opening the issue at the CSAF TC repo.

To answer your question, I can only speak for Cisco. Very relevant to this conversation and feature (one of the reasons I also suggested it 😆). Cisco is working on some final minor tweaks on a few signature related issues in the publication process. They are expected to become a "trusted provider in just a few weeks.

As a side note and for the benefit of everyone reading this issue, you can also see some examples of open source CSAF validation tools at https://csaf.io and also an example of a CSAF provider at https://github.com/csaf-poc/csaf_distribution/blob/main/docs/csaf_provider.md

Many other companies are also adopting CSAF at a very rapid pace nowadays. RedHat, Oracle, CISA, Nozomi, Open Exchange, and Sick.com are other examples.

Thank you again for all your time, help, and amazing contributions!

[wurstbrot]

@santosomar
Thank you for clarification.

It would be very nice if you check the CSAF documents in the PR.

I also think that a CSAF document for an application with intentional vulnerabilities might be something new, also for the CSAF standard.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. 📆 It will be closed automatically in one week if no further activity occurs.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. 📆 It will be closed automatically in one week if no further activity occurs.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.

[yeajun001]

how to solve this problem ?

Security Advisory

I copied it the same way as above, but I don't get stars.

[wurstbrot]

Hi @yeajun001 ,

thank you for your request. What did you submit? You can also send me a message in owasp slack.