[fix][core] keep segmentation values out of Object.prototype

[ar2rsawseen]

What was wrong

An event segmentation value on the unauthenticated /i endpoint becomes a MongoDB field name at d.<day>.<value>.<metric>. A value of __proto__ passed every transform — no $, no ., not one of the day numbers in forbiddenSegValues — and stored a document with a literal __proto__ field.

On read, deepMerge in fetch.js walks the document with for...in. The driver returns __proto__ as an own enumerable property, so the loop yields it, and:

else if (ob1[i] && typeof ob1[i] === "object") {
    ob1[i] = deepMerge(ob1[i], ob2[i]);   // ob1["__proto__"] is Object.prototype
}

merges the stored object into Object.prototype of the worker. That persists for the worker's whole life, so every later read, for every app it serves, returns corrupted numbers. The daily api:topEvents job triggers the read across all apps unprompted.

#7634 guarded the segmentation key. This is the value path four lines down, which that guard never reached, plus two more sites of the same class and the sink itself.

What changed

• common.isForbiddenFieldName — one predicate for __proto__ / constructor / prototype, now also used by the key guard #7634 hard-coded, so the whole class reads through one function.
• events.js — the segmentation value is prefixed with [CLY] when it names a prototype member, exactly as forbidden day numbers already are.
• common.js recordSegmentMetric — the same for the metric value, which builds an identical d.<...> field name.
• fetch.js deepMerge — skips inherited keys (hasOwnProperty) and the three names. This is the durable guard: it also neutralises documents already poisoned in existing databases, which the input guards alone cannot, since those re-pollute on every read.

Verified against the unpatched code

The real deepMerge was lifted and fed a document with an own-enumerable __proto__ field, the way the mongo driver deserializes one:

before (pristine):  ({}).c = 100   ({}).s = 500   -> Object.prototype polluted process-wide
after  (patched):   ({}).c = undefined            -> clean, and a legitimate merge still sums (Chrome.c = 6)

Unit test test/unit-tests/api.data.segmentation-value-prototype.js: the exported predicate, plus source-level assertions that the two value paths run through it and that deepMerge skips inherited and prototype-member keys. 5 cases, all failing against the unpatched files.

Scope

The corruption is in the running process, not the stored data — the database is never wrong, and a poisoned document re-pollutes each fresh worker on read until the code is fixed. Property names are confined to the common.dbMap metrics and the values are numbers, so this is data-integrity corruption, not RCE.

Second sink, found after the first commit

getMergedEventData in the same file walks stored event documents through five nested for...in levels and merges with mergedEventOutput[l1][l2][l3][l4][l5] += …. Same defect, same reachability: a segmentation value is a key at those levels, and each level's guard is if (!mergedEventOutput[…]), which a prototype is truthy for, so it is never replaced before the assignment writes through it.

Fixing deepMerge alone therefore left the read path exploitable from any already-poisoned document, which defeats the point of the sink fix.

Worth recording why it was missed: it is not named like a merge helper and it does not recurse, so both a search for merge functions and a search for recursive walkers skip it. Only a search for nested bracket assignment finds it.

• isMergeableKey is now the single guard for every walk of a stored document in this file, and deepMerge uses it too.
• All five levels guarded, plus the meta reduce, where a prototype key would call .concat on Object.prototype and throw rather than pollute.

Proof, on all three targets:

before:  ({}).c = 7   ({}).s = 77   -> polluted process-wide from one merged document
after:   ({}).c = undefined         -> clean, Chrome.c still 3+3 = 6

The harness runs the lifted loop in the host realm rather than a vm context. A vm has its own Object.prototype, so pollution inside it is invisible to a probe outside and the test passes either way; my first attempt at this made exactly that mistake.

---

Client / dashboard side (added in this PR)

The same class exists in the dashboard: a segmentation value, event key or metric name becomes an object key in the browser too, and an API response delivered as JSON can carry __proto__ as an own enumerable property. Two hand-rolled merges in countly.common.js write through such a key and reach Object.prototype for the life of the page.

• countlyCommon.isForbiddenFieldName — the browser mirror of the server predicate.
• mergeMetricsByName — pollutes through a data value index (uniqueNames[newName][k], newName a segmentation/range value); the value is now skipped before use.
• extendDbObj — walks a fetched day document with for (var level1 in …); the existing hasOwnProperty does not exclude an own __proto__, so both levels now skip the prototype names.
• The seven segmentation/response for…in walks in countly.event.js (readers / write-AT loops), guarded for consistency.

Proof, real functions lifted out of the browser IIFE and fed an own-__proto__ payload:

before:  ({}).mmbn_marker = "PWN"   ({}).edo_marker = 7   -> Object.prototype polluted page-wide
after:   both undefined                                   -> clean, and Chrome still sums to 5

The eslint rule, extended to the dashboard

no-prototype-pollution-sink was scoped to api/** + plugins/*/api/**. It is now also switched on for frontend/express/public/javascripts/countly/** and plugins/*/frontend/**, and every site it reports there is guarded in source — keeping the no-exceptions contract. It surfaced two genuinely global sinks the manual review had not named:

• plugins/views countly.models.js — for (var k in json) over an API response, writing through _graphDataObj[k][z].
• plugins/sources countly.views.js — an index through a source name derived from the response; fixed by skipping the prototype names and writing onto an already-selected bucket, so the derived value no longer sits mid-chain in the assignment target.

The remaining reports (auth app / permission maps, the session sparkline walk, the two _myRequests walks, the sdk config and push emoji loops) iterate objects the code builds itself, so the guard is a cheap no-op that keeps the rule clean. eslint reports 0 across api + plugins-api + frontend + plugins-frontend.

Proof, the two global plugin sinks:

before:  ({}).pollViews = {x:1}   ({}).PWN = {...}   -> polluted page-wide
after:   both undefined                              -> clean, real view/source still processed

Unit test test/unit-tests/frontend.segmentation-value-prototype.js: the predicate, the two lifted common.js sinks and two lifted event.js functions run on an own-__proto__ payload, plus guard-presence and eslint-scope assertions and a behavioural proof for the two plugin sinks. 21 cases.