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
Did not mention nested non-member interfaces and record classes.
The documentation of the overridden `isStatic()` predicate already mentions
that this predicate holds for explicitly and implicitly static elements, so
overwriting it is not necessary and only adds more maintenance work.
The changes to `ModificationOfParameterWithDefault.ql` and the use of
`ConditionBlock::controls` therein caused the `BasicBlock` argument to
get magicked in, resulting in the following antijoin for the `forall`:
```
[2021-10-04 12:07:46] (108s) Tuple counts for GuardedControlFlow::ConditionBlock::controls_dispred#fbf#antijoin_rhs/5@d84e94 after 1m44s:
201222345 ~7% {5} r1 = JOIN GuardedControlFlow::ConditionBlock::controls_dispred#fbf#shared#2 WITH Flow::BasicBlock::getASuccessor_dispred#ff_10#join_rhs ON FIRST 1 OUTPUT Lhs.0 'arg1', Rhs.1 'arg4', Lhs.1 'arg0', Lhs.2 'arg2', Lhs.3 'arg3'
200599933 ~4% {5} r2 = JOIN r1 WITH Flow::BasicBlock::dominates#ff ON FIRST 2 OUTPUT Lhs.2 'arg0', Lhs.0 'arg1', Lhs.3 'arg2', Lhs.4 'arg3', Lhs.1 'arg4'
0 ~0% {4} r3 = JOIN GuardedControlFlow::ConditionBlock::controls_dispred#fbf#shared#1 WITH GuardedControlFlow::ConditionBlock#class#f ON FIRST 1 OUTPUT Lhs.0 'arg3', Lhs.2 'arg1', Lhs.1 'arg0', false
0 ~0% {4} r4 = JOIN GuardedControlFlow::ConditionBlock::controls_dispred#fbf#shared WITH GuardedControlFlow::ConditionBlock#class#f ON FIRST 1 OUTPUT Lhs.0 'arg3', Lhs.2 'arg1', Lhs.1 'arg0', true
0 ~0% {4} r5 = r3 UNION r4
0 ~0% {5} r6 = JOIN r5 WITH Flow::BasicBlock::getASuccessor_dispred#ff ON FIRST 2 OUTPUT Lhs.2 'arg0', Lhs.1 'arg1', Lhs.3 'arg2', Lhs.0 'arg3', Rhs.0
200599933 ~4% {5} r7 = r2 UNION r6
return r7
```
(cancelled)
I observed that quick-eval'ing the `controls` predicate exhibit no such
bad join order (and terminated quickly) which lead me to conclude that
this was a case of bad magic.
Adding the `pragma[nomagic]` resulted in a return to the previous
performance.
