Queries / tests that required changes:
* The CleartextLogging and MissingErrorCheck queries are updated because they assumed def-use flow
* The CommandInjection query works around the shortcomings of use-use flow by essentially reintroducing def-use flow when it applies a sanitizer
* The OpenUrlRedirect query currently just accepts its fate; the tests are updated to avoid excess sanitization while the query comments on the problem. We should choose this approach or the CommandInjection one.
`localTaintStep` includes a lot of steps which are already part of value
flow. Instead use `defaultAdditionalTaintStep`, which is just the extra
steps that are added for taint tracking.
The extra nodes in .expected files are due to the changes from
https://github.com/github/codeql/pull/13717, which are not applied to
configuration classes extending DataFlow::Configuration or
TaintTracking::Configuration.
In the `subpaths` section, the last node is now printed without its type
if it is the sink of the path.
This comes from the commit "Dataflow: Bugfix: include subpaths ending at
a sink. " in https://github.com/github/codeql/pull/7526
This query already treats structs differently to usual: it includes field -> whole struct taint steps, but explicitly excludes struct -> field steps. This means that a logging framework sinking an entire struct with a tainted field yields an alert, but we don't get FPs caused by writing field `x` but then reading field `y`.
However, protobuf messages have a special treatment, with taint usually associated with the whole struct and getter methods propagating that taint out. Suppressing these getter method steps specifically for the cleartext-logging query mirrors its treatment of structs in general and avoids this sort of field-mismatch FP.
On the downside we will miss same-field propagation like `m.field = password; Log(m.GetField())` if we don't have source code for the implementation of `m`. However this is hopefully unusual since the typical use of protobufs is to serialize and deserialize, rather than using the struct as a general-purpose datastructure.
