JS: Add sources and sinks related to GitHub Actions

[asgerf]

Adds sources and sinks based on this PR from @R3x with comments from @JarLob.

This PR is essentially a port of that PR with the following differences:

• Use API graphs, to ensure global tracking of intermediate values
• Deduplicate code using set literals and intermediate predicates
• Populate concepts rather than adding new queries
• Target mainline instead of experimental
• Write tests closer to how we normally do it

I couldn't foresee a practical way to get the original PR to this state via code reviews, hence this new PR.

But I'd like to give credit for @R3x and @JarLob for authoring the models. These were just some changes needed to get the models into a format where we can use it outside of experimental.

[R3x]

Hi @asgerf, Thanks for the updates.

Is it possible to not combine these sources? I noticed that the same taint source is used for both the inputs as well as context. I feel that splitting these up makes more sense.

Github Context directly to JS sink is of higher severity, than the Action Input to Sink or the Environment variable to the sink.

If there is a Github Context to Sink vulnerability then it affects all the workflows that are used by the action, whereas if it's the latter, then it affects only the workflows that are passing tainted input into these Actions either as an Input or as an environment variable.

Also, can we also taint the environment variables? I used a list to filter out the names of the ones that are set by the runner, the others can still be tainted. Note that this query can suffer from some loss in precision - if the action itself is setting the environment variable and then using it (although I haven't seen it in practice).

[R3x]

Should this be in javascript/ql/src/change-notes instead - it was added in ruby?

[asgerf]

Is it possible to not combine these sources? I noticed that the same taint source is used for both the inputs as well as context. I feel that splitting these up makes more sense.

There is some work in progress that would enable a more fine-grained classification of taint sources, but for the moment we have to either include these taint sources or not. But I've made it more clear in the source code that there is a difference in severity so it's easier to review in the future.

Also, can we also taint the environment variables?

As mentioned above, we don't currently have fine-grained classification of sources. For now I've updated IndirectCommandInjection to block flow through the environment variables you listed. This query treats environment variables as taint sources.

Should this be in javascript/ql/src/change-notes instead - it was added in ruby?

Thanks for pointing that out, obviously it should be in the JS folder

[asgerf]

After reviewing some more of the results this change would produce, we're going to restrict the getInput() source to just the indirect command-injection query for now.

[erik-krogh]

Single optional comment, there was one predicate you had not made private.