feat(call-graph): attribute method calls on untyped receivers so DB sinks are reachable

[rahlk]

Plan

roadmap — discovered while evaluating whether OWASP NodeGoat is sufficiently modelled for security triage. Sibling of #85.

Problem

Method calls on a value that has no resolvable type produce no call-graph edge and no external symbol, so the database layer of a typical Node app is invisible.

Measured on NodeGoat (--eager -a 2, dependencies installed):

route -> mongodb path: NO PATH
callers of mongodb nodes: (none — every mongodb node is a graph root)

The 22 external symbols include needle.get, node-esapi.encoder and several mongodb:* entries, but the mongodb ones come from connection setup in server/config code. The actual query sinks produce nothing:

// app/data/allocations-dao.js
15    const allocationsCol = db.collection("allocations");
29    allocationsCol.update({ … });
86    allocationsCol.find(searchCriteria()).toArray((err, allocations) => { … });

db is an untyped constructor-function parameter. The tsc resolver cannot type it, so resolveCalleeSignature fails; the phantom fallback (src/semantic_analysis/phantoms.ts) only indexes require() of external specifiers at top level, so there is nothing to attribute the call to either.

Consequence: the question "does user input from POST /allocations reach a Mongo query?" — the NoSQL-injection case, and squarely the COCOA/PoE use case — cannot be answered from the graph.

Scope boundary

Makes unresolved method calls on untyped receivers attributable, so a security consumer can reach the sink. Does not:

• attempt real points-to or type inference for untyped values;
• invent edges to a specific library when the receiver's origin is genuinely unknown;
• change the schema — call sites already carry method_name and receiver_expr;
• fix the missing DAO methods themselves, which is feat(symbol-table): materialize this.x = fn and object-literal methods as callables #85 and must land first.

Ordering note — test this after #85

There is a strong hypothesis that #85 fixes much of this by itself. The jelly leg currently reports 3725 dropped edges, and jellyProvider drops any edge with an unresolved endpoint. Today the DAO methods are not callables at all, so every edge whose source is a DAO method is dropped regardless of whether jelly traced it. Re-measure after #85 before designing anything here; the residual may be small.

Goals

• Re-measure NodeGoat after feat(symbol-table): materialize this.x = fn and object-literal methods as callables #85 lands and record what remains unreachable
• For a call whose receiver traces to a parameter, record enough on the call site to attribute the sink (receiver expression and the parameter it binds to)
• Where the receiver's origin is a first-party parameter, emit an edge or a phantom rather than silently dropping the call
• Fixture: a constructor function taking an untyped db parameter, calling db.collection("x").find(...)

Caveats and known risks

• Flooding. Attributing every unresolved method call on every unknown receiver would add large numbers of low-value edges. Any attribution must be bounded — e.g. only where the receiver is traceable to a declared parameter of an enclosing first-party callable.
• Wrong attribution is worse than none for security triage. A false edge into a sink manufactures a vulnerability. Prefer recording call-site evidence over synthesizing an edge when the target is uncertain.
• Jelly overlap. Jelly already reaches into mongodb from connection code. Once feat(symbol-table): materialize this.x = fn and object-literal methods as callables #85 lands, some of these edges may arrive from jelly for free; duplicating them via tsc must coalesce on the (source, target) key.
• Scope is the v1 (0.x) line.

Definition of done

• On unmodified NodeGoat, a path exists from an app/routes/* node to a Mongo query sink, and it is reported in the PR with the exact hop sequence.
• The DAO query calls at allocations-dao.js:29 and :86 are attributable to a sink from the analysis output alone.
• No edge is emitted whose target is a guess: every new edge is justified by a traceable receiver origin, and the fixture asserts the negative case (genuinely unknown receiver ⇒ no edge).

[rahlk]

Measured after #85 landed. The ordering hypothesis in this issue is falsified, and the security goal is largely met — but not the way this issue proposes.

The hypothesis was wrong. I predicted #85 would unlock jelly's dropped edges. Jelly's numbers are byte-identical before and after: 156 edges (39 library-boundary), 3725 dropped. Those drops are not caused by missing first-party callables.

No mongodb edge appeared, as this issue predicted:

route -> mongodb path: NO PATH
mongodb targets with first-party callers: none

But the chain is now fully attributable without one. #85 supplied the missing middle, and the receiver's origin was already being recorded — I had simply filtered it out of my earlier query:

app/routes/allocations.AllocationsHandler.displayAllocations       (edge)
  -> app/data/allocations-dao.AllocationsDAO.getByUserIdAndThreshold  (edge — new in #85)
       call_site:  find(...)  receiver_expr='allocationsCol'  line=86
       local_variables: allocationsCol  initializer='db.collection("allocations")'
       parameters: [db]

So "does user input from POST /allocations reach a Mongo query?" is answerable from the analysis output today: the route reaches the DAO method by edges, and the sink call is homed on that method with its receiver traced to a constructor parameter. Locked in by a regression test on the idiom-app fixture.

What actually remains is only a real edge into the mongodb package. Proving db is a mongodb Db requires interprocedural points-to — db is a parameter, passed from the handler, originating at MongoClient.connect in server.js. Synthesizing that edge from the method name would violate this issue's own definition of done ("no edge is emitted whose target is a guess"), and a false edge into a sink manufactures a vulnerability.

Recommendation: narrow this issue to the points-to work and park it against the v2 dataflow line (L3/L4), rather than implementing a heuristic on 0.x. Deliberately not implementing one.