Skip to content

security: encode and sanitize values at frontend HTML sinks (24.05) - #7971

Open
ar2rsawseen wants to merge 6 commits into
release.24.05from
backport/xss-sink-hardening-2405
Open

security: encode and sanitize values at frontend HTML sinks (24.05)#7971
ar2rsawseen wants to merge 6 commits into
release.24.05from
backport/xss-sink-hardening-2405

Conversation

@ar2rsawseen

Copy link
Copy Markdown
Member

Backport of #7970 to release.24.05. Consolidates the frontend HTML-sink hardening work into one PR; each change routes an attacker-influenceable value through the right encoder/sanitizer at the point it enters an HTML sink, leaving normal display unchanged. Replaces #7967, #7969, #7962, #7965 and #7950.

  • core / graph note tooltip — HTML-encodes the application name before rendering (countly.common.js).
  • push / message editor — sanitizes the composed message before it is set as innerHTML on the editor's contenteditable, allowing only the user-property token span and its attributes.
  • compliance-hub / export history — HTML-encodes the application name in the action cell; API-escaped values are left untouched, with a comment and a unit test guarding both directions.
  • populator / confirm dialogs — dialog bodies render as text instead of HTML.
  • core / res.expose script island — escapes < when serializing countlyGlobal into the inline page script; the active-app name is rendered with .text() instead of .html().

Verified: node --check and eslint on all changed JS; compliance-hub escaping unit test passes (5/5).

🤖 Generated with Claude Code

ar2rsawseen and others added 6 commits August 19, 2026 17:11
…oltip

Backport of #7966 to release.24.05.

The graph-note tooltip builds an HTML string including the application name from
countlyGlobal (raw at runtime) and renders it via tipsy html:true. Encode it with
countlyCommon.encodeHtml so it renders as text. Display unchanged.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…contenteditable

The push message editor set the composed message as innerHTML on a live
contenteditable. Sanitize that content with countlyCommon.encodeSomeHtml, allowing only
the user-property token span (and the attributes it relies on: class, id, contenteditable,
data-user-property-*) and escaping any other markup to inert text. The message body is
user text and the token element is the only legitimate markup, so display is unchanged for
normal messages; the token id is preserved so the editor's per-token event wiring keeps
working.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…istory actions column

Backport of the master change.

The export/purge history datatable builds an html string in onReady and the
template renders it, so every value interpolated into it has to be html-safe
before it gets there.

Values taken from the row arrive through common.returnOutput, which
escape_html_entities has already escaped, so they are deliberately left alone:
escaping them a second time would surface the entities literally in the ui.
One value in that string comes from countlyGlobal instead. That object is
serialized into the dashboard by express-expose, whose escaping is for the
javascript string context and is value-preserving by design, so the api's html
escaping never applied to it. It is now escaped where it is interpolated.

Adds test/unit-tests/plugins.compliance-hub.actions-escaping.js, which loads
the real module in a sandbox and exercises the actual onReady builder. It pins
both directions: a value carrying markup is neutralized, and an already-escaped
api value is not double-escaped.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ete confirmations

Backport of the master change, adjusted for this branch: the two populator
delete confirmations need different fixes here, because their localized strings
differ from master's.

Both dialogs substitute a name that was html-decoded on the way in, so the
escaping the api applied no longer held by the time it was rendered.

- the template delete confirmation carries no markup in any of the 26 locale
  files, so its body is now text interpolation, which removes the sink
- the environment delete confirmation cannot do that on this branch. Its string
  is "Are you sure you want to delete <b>{0}</b> environment?", so the body has
  to stay v-html and the name is escaped where it is substituted instead. On
  master the same string has no markup, which is why that branch converts the
  template and this one does not.

Left the plugins plugin's dependency confirmation on v-html, as on master:
plugins.confirm carries a <br/><br/> in all translated locale files, and the
values interpolated into it are plugin titles from package metadata rather than
anything a dashboard account can write.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…S via app name)

Backport of #7949 to release.24.05.

The dashboard serialises the exposed countlyGlobal object into an inline
<script> block. The serialiser only neutralised the exact sequence
"</script>", but the HTML tokeniser also ends a script element at
"</script >", "</script/>" and other whitespace/slash spellings, so an
application name containing one broke out of the script block. An app admin
of a single app could store such a name; any global admin who then loaded
the dashboard (which lists every app) executed the attacker's markup in
their own session, escalating an app-admin account to global-admin control.

Escape every "<" as < in both serialisation paths (string values and
object keys). < parses back to "<", so every value read from the exposed
object is unchanged; verified by an eval round-trip that reproduces the
input object identically and matches the previous serialiser output.

Also render the active-app name with .text() instead of .html() in
countly.template.js, an independent DOM sink for the same value.

Reported through the security bug bounty programme (received 2026-08-17).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ent version

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant