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
We have internal material on this subject, so it makes sense to have a reference example.
Bazel builds could be in any compiled language, so follow the pattern
of the generic build script example.
Include the build flags that we recommend to customers,
which turn off Bazel's caching and distributed behaviour
so that CodeQL can observe the entire build.
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.
