At which level do we want to solve code injection issues

[jonaslagoni]

Reason/Context

Even though the AsyncAPI document itself is safe, in the context it is used it can become an attack surface. This is especially relevant in code generation aspects, where values from the AsyncAPI documents can be used as-is.

I would like to discuss at which "level" should this issue be handled so we can take the appropriate actions.

Scope of the issue

Use-cases/libraries where this is a problem:

• Generator, and all templates that do not manually handle this.
  • The nunjucks rendering engine is "safe" per default, as you have to use {{somevariable | safe}} to get around the escaping of values. It escapes the values based on simple regex and it would cover most cases I think. However, only as long as safe is not used.
  • The react rendering engine does not escape any values per default. Some templates might have their own sanitation.
• Modelina
  • As we generate models based on the AsyncAPI/JSON Schema definition, to multiple languages
• React components
  • As they are generally used to integrate into a website.
• Others?

Public related advisories:

• GHSA-xj6r-2jpm-qvxp
• GHSA-4jg2-84c2-pj95

Solutions

These are the following potential solutions we could take a look at (Thanks for brainstorming @magicmatatjahu @smoya):

1. Introducing sanitizing in parsers. This will solve it at a "global" level.
   • Example could be to introduce a safe configuration that the dependant libraries can use (even when they are not).
   • We are however not sure if we can sanitize values accurately for each language they are used in.
2. Acknowledging the problem is enough, and assume AsyncAPI documents will always be safe (even if they are not).
3. Warn user about potential code injection if found, can be done with something similar to static code analysis.
4. Let each library solve the sanitation problem on their own based on what they output to (HTML, Java, TS, etc).
5. Other?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[derberg]

imho decision for this is on library level