This means we treat != comparisons against strings as taint tracking guards:
if foo != "A"
foo # still tainted
else
foo # not tainted, because we know foo == "A"
end
We don't (yet) properly sanitize taint in cases like this
foo = "A" unless foo == "B"
So for now, use a simpler guard in the SQL injection test.
We can resurrect the old, more idiomatic guard when we can support it.
Following examples from the other libraries, this change introduces a
member predicate `checks(CfgNode expr, boolean branch)` to
`BarrierGuard`, which holds if the guard validates `expr` for a
particular value of `branch`, which represents the value of the
condition in the guard.
For example, in the following guard...
if foo == "foo"
do_something foo
else
do_something_else foo
end
...the variable `foo` is validated when the condition `foo == "foo"` is
true.
We also introduce the concept that a guard "controls" a code block based
on the value of `branch`. In the example above, the "then" branch of the
if statement is controlled when `branch` is true. The else branch is
not controlled because `foo` can take (almost) any value in that branch.
Based on these concepts, we define a guarded node to be a read of a
validated variable in a controlled block.
In the above example, the `foo` in `do_something foo` is guarded, but
the `foo` in `do_something_else foo` is not.
This query finds instances of CWE-601: Redirection to Untrusted Site.
The structure is copied from a query of the same name in the Python
library. We add customisations specific to `ActionController`.
The previous version of this query inadvertently excluded constants
which weren't classes or modules. This version includes them, by
introducing a laxer version of `resolveScopeExpr` that doesn't require
the result to be a `TResolved`.
By convention, instance variables are considered to be "defined" in the
`#initialize` method of their containing class. If an instance variable
is written to in `#initialize` and then read elsewhere in the program,
we will point from the read to the write. If it is not written to in
`#initialize` then we won't provide any jump-to-definition information
for it.
We synthesise variables for things like tuple patterns. For example,
this Ruby code:
a, b = ...
becomes:
__synth__0 = ...
a = __synth__0[0]
b = __synth__0[1]
The `__synth__` variables should be ignored when calculating
jump-to-definition information, since they don't appear in the original
source code.
The expected output format is a tuple (a, b, k) where `a` and `b` are any
`AstNode` subclass and `k` is a string indicating the kind of
definition (e.g. variable, method, ...).
By ensuring that every value in `DefLoc` is a subclass of `Expr` (itself
a subclass of `AstNode`) we can simplify the query by removing all the
use of `getLocation()`.
