Second batch of test reblessings, capturing changes in result content
(not just toString labels):
- Framework taint/concept tests (fastapi, sqlalchemy, aiohttp, lxml,
stdlib, django-orm): mostly gained MISSING-tainted annotations where
the new dataflow no longer reaches sinks. Some are real taint
regressions; left as documented failures for follow-up.
- Exception-handler tests (CWE-209-StackTraceExposure, EmptyExcept,
CatchingBaseException, IncorrectExceptOrder, FileNotAlwaysClosed,
FindSubclass/Find, Statements/exit/UseOfExit): the no-raise shared CFG
abstraction does not emit ExceptionSuccessor abrupt-completion edges
from arbitrary expressions, so except-handler bodies (and their
exception target Names) are statically dead. Tracked separately under
cfg-modelling-exceptions.
- Dataflow-path / control-flow node toString polish across the security
query suite (PathInjection, CodeInjection, UnsafeUnpacking,
UnsafeUsageOfClientSideEncryptionVersion, RequestWithoutValidation,
ReflectedXss, CallGraph): simple-leaf nodes now stringify as their
AST text instead of 'After X'.
- SSA / call-graph improvements (CmpTest, CallGraph/InlineCallGraphTest):
fewer SSA mismatches between new and old; two previously-MISSING tt=
annotations resolved.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The shared CFG library overrides ControlFlowNode.toString() as 'final'
(shared/controlflow/codeql/controlflow/Cfg.qll:1217), so the legacy
'ControlFlowNode for X' prefix is gone — the new toString returns just
'X' for normal nodes and 'After X' for after-nodes. This produces a
large cosmetic diff in test expected files with no semantic change.
Mass-rebless 78 .expected files whose actual output differs from the
checked-in expected only by this rename. Each file was verified to be
identical after normalising 'ControlFlowNode for ' and 'After ' away
from both sides.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Four library/query files still referenced the legacy Flow.qll `ControlFlowNode`
and friends, which no longer match the dataflow library's `Cfg::ControlFlowNode`:
- SubclassFinder.qll: type `value` as `Cfg::ControlFlowNode`.
- ExceptionInfo.qll: replace `EssaNodeDefinition.getDefiningNode()` filter
with `Cfg::NameNode.defines(_)` (the legacy ESSA class isn't reachable
through the new dataflow API at the query-pack layer).
- ServerSideRequestForgeryCustomizations.qll: qualify `BinaryExprNode` with
`Cfg::` and update `stringRestriction` to take `Cfg::ControlFlowNode`.
- TarSlipCustomizations.qll: qualify `CallNode`/`AttrNode`/`NameNode` and
the `tarFileInfoSanitizer` parameter with `Cfg::`.
The three reblessed `.expected` files are purely cosmetic toString churn
("ControlFlowNode for X" -> "X", "After X"); verified set-equal after
normalising the toString prefixes.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Looking at the results of the the previous DCA run, there was a bunch of
false positives where `bind` was being used with a `AF_UNIX` socket (a
filesystem path encoded as a string), not a `(host, port)` tuple. These
results should be excluded from the query, as they are not vulnerable.
Ideally, we would just add `.TupleElement[0]` to the MaD sink, except we
don't actually support this in Python MaD...
So, instead I opted for a more low-tech solution: check that the
argument in question flows from a tuple in the local scope.
This eliminates a bunch of false positives on `python/cpython` leaving
behind four true positive results.
This takes care of most of the false negatives from the preceding
commit.
Additionally, we add models for some known wrappers of `socket.socket`
from the `gevent` and `eventlet` packages.
Adds test cases from github/codeql#21582 demonstrating false negatives:
- Address stored in class attribute (`self.bind_addr`)
- `os.environ.get` with insecure default value
- `gevent.socket` (alternative socket module)
In hindsight, having a `.getMetrics()` method that just returns `this`
is somewhat weird. It's possible that it predates the existence of the
inline cast, however.
Our previous modelling did not account for the fact that a lookahead can
potentially extend all the way to the end of the input (and similarly,
that a lookbehind can extend all the way to the beginning).
To fix this, I extended `firstPart` and `lastPart` to handle lookbehinds
and lookaheads correctly, and added some test cases (all of which yield
no new results).
Fixes#20429.
