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>
Library-test compile fixes after the shared-CFG migration:
- PointsTo/global, PointsTo/local: use `f.getNode() = s.getValue()`
instead of `s.getValue().getAFlowNode() = f` (the new CFG does not
surface getAFlowNode on AST nodes).
- PointsTo/new/ImpliesDataflow: bridge new Cfg::ControlFlowNode to the
legacy ControlFlowNodeWithPointsTo via AST identity.
- frameworks/aiohttp + frameworks/modeling-example: qualify CallNode /
NameNode / AttrNode casts with Cfg:: now that those names live in
the new CFG facade.
Rebless 4 expected files for toString-only differences (renamed CFG
positions like 'CFG node for foo' vs 'foo' — no semantic change):
ImpliesDataflow, EnclosingCallable, NaiveModel, ProperModel.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
However, notice that the concepts tests use the HttpResponse location
for the `responseBody` tag, which seems a little odd in this situation,
where they are actually separate. Will fix in next commit.
along with tests, but no implementations (to ease reviewing).
---
I've put quite some thinking into what to call our concept for this.
[JS has `CookieDefinition`](581f4ed757/javascript/ql/src/semmle/javascript/frameworks/HTTP.qll (L148-L187)), but I couldn't find a matching concept in any other languages.
We used to call this [`CookieSet`](f07a7bf8cf/python/ql/src/semmle/python/web/Http.qll (L76)) (and had a corresponding `CookieGet`).
But for headers, [Go calls this `HeaderWrite`](cd1e14ed09/ql/src/semmle/go/concepts/HTTP.qll (L97-L131)) and [JS calls this `HeaderDefinition`](581f4ed757/javascript/ql/src/semmle/javascript/frameworks/HTTP.qll (L23-L46))
I think it would be really cool if we have a naming scheme that means the name for getting the value of a header on a incoming request is obvious. I think `HeaderWrite`/`HeaderRead` fulfils this best. We could go with `HeaderSet`/`HeaderGet`, but they feel a bit too vague to me. For me, I'm so used to talking about def-use, that I would immediately go for `HeaderDefinition` and `HeaderUse`, which could work, but is kinda strange.
So in the end that means I went with `CookieWrite`, since that allows using a consistent naming scheme for the future :)
Since we want to be able to easy select request-handlers that are not
set up as part of a view-class, we need to easily be able to identify
those. To handle cases like the one below, we _can't_ just define these
to be all the async functions that are not methods on a class :(
```py
# see https://docs.aiohttp.org/en/stable/web_quickstart.html#organizing-handlers-in-classes
class MyCustomHandlerClass:
async def foo_handler(self, request): # $ MISSING: requestHandler
return web.Response(text="MyCustomHandlerClass.foo")
my_custom_handler = MyCustomHandlerClass()
app.router.add_get("/MyCustomHandlerClass/foo", my_custom_handler.foo_handler) # $ routeSetup="/MyCustomHandlerClass/foo"
```
So it seemed easiest to narrow down the route-setups, but that means we
want both refinement and extensibility... so `::Range` pattern to the
rescue 🎉
The important piece of code that still works after this commit, but
which hasn't been changed, is the one below:
```codeql
/**
* A parameter that will receive a `aiohttp.web.Request` instance when a request
* handler is invoked.
*/
class AiohttpRequestHandlerRequestParam extends Request::InstanceSource, RemoteFlowSource::Range,
DataFlow::ParameterNode {
AiohttpRequestHandlerRequestParam() {
exists(Function requestHandler |
requestHandler = any(AiohttpCoroutineRouteSetup setup).getARequestHandler() and
```
