Also, change some examples pack names from `codeql-lang-examples` to
`codeql/lang-examples`. This doesn't affect behaviour since internally,
the legacy name is converted to the modern name.
The two files moved in this commit are referenced from the
javascript/lib qlpack, but they are located in the
javascript/src qlpack. This causes compile errors when running
compile-ish commands for javascript queries. Moving the
files fixes it.
The derived security-severity score of the JS code injection query
was much lower than for other languages (6.1 versus 9.3), possibly due
some differences in CWE tags, such as the inclusion of CWE-079.
We also add the more specific CWE-095 ("eval injection") for consistency
with other languages. It is a child of CWE-094 ("code injection") which
was already tagged.
This is a denial-of-service query, but was missing the CWE-730 tag
("denial of service") and consequently had a lower score than the
other DoS queries.
The CWE number for this query is associated with buffer overflows
from printf/scanf-style functions in C++, which has likely determined
its derived security score.
But in JavaScript, a tainted format string is unlikely to lead to
anything worse than log injection so we're manually update its score
to reflect this.
In the CVSS calculator we model this by setting 'Attack Complexity' to
High and 'User Interaction' to Low (as opposed to None).
CVSS vector:
CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:H/A:N
This commit ensures consistency among all of our qlpacks. Here are the
changes:
1. Ensure only modern references are used (codeql-{lang} is converted to
codeql/{lang}-all or codeql/{lang}-queries where appropriate).
2. Use consistent version numbers. All languages are at 0.0.2 except
javascript, which is 0.0.3.
3. Convert all `libraryPathDependencies` to `dependencies` with version
constraints
4. Dependencies from query packs to other packs are always `"*"` since
these dependencies are always from source and we should get the
latest.
5. Dependencies from codeql/{lang}-lib to codeql/{lang}-upgrades must
be strict since there is a tight connection between the libary
and its relevant upgrades.
