From d8880dc1d84d6cb935d6683fa129a13a94fac222 Mon Sep 17 00:00:00 2001 From: seonghobae <8172694+seonghobae@users.noreply.github.com> Date: Mon, 5 Oct 2026 14:47:04 +0000 Subject: [PATCH] =?UTF-8?q?=F0=9F=9B=A1=EF=B8=8F=20Sentinel:=20[HIGH]=20Fi?= =?UTF-8?q?x=20DOM=20XSS=20via=20unescaped=20numeric=20properties=20in=20c?= =?UTF-8?q?onsole?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .jules/sentinel.md | 5 +++++ scanner/dashboard/console.html | 18 +++++++++--------- 2 files changed, 14 insertions(+), 9 deletions(-) diff --git a/.jules/sentinel.md b/.jules/sentinel.md index 1600d4323..3e755feac 100644 --- a/.jules/sentinel.md +++ b/.jules/sentinel.md @@ -127,3 +127,8 @@ **Vulnerability:** The `/api/v1/webhook` POST endpoint in `appguardrail_core/controlplane.py` failed to validate the `url` property when accepting it into the database, leading to Stored SSRF risks. In addition, the core SSRF validation logic (`_is_safe_url`) in both the CLI and control-plane did not verify the input type (e.g. `isinstance(url, str)`). Passing non-string types (like integers) resulted in unhandled `AttributeError` exceptions inside `urllib.parse.urlparse`, which led to API 500 crashes on malicious JSON payloads. **Learning:** Network endpoints must explicitly validate the data type of user-provided configurations prior to execution or storage. Furthermore, webhooks configured by users should always be checked for SSRF when saved, as trusting them later assumes input has already been safely validated, bypassing downstream network guardrails. **Prevention:** Apply `_is_safe_url` checks directly upon ingestion (e.g., in `/api/v1/webhook`) and enforce type checks `if not isinstance(url, str): return False` prior to using library parsing functions like `urlparse`. Always return gracefully failing responses (like `400 Bad Request`) for unsafe URLs instead of allowing unhandled 500 server errors. + +## 2026-10-05 - [DOM XSS via unescaped numeric properties in dashboard] +**Vulnerability:** DOM XSS via unescaped numeric properties (like `deploy_blocking`, `new_blocking`, `total`) injected into `innerHTML` in `scanner/dashboard/console.html`. +**Learning:** Even numeric or seemingly safe meta-fields like counts can contain malicious payloads if sourced from untrusted JSON payloads and directly injected into innerHTML without explicit string sanitization or type coercion. +**Prevention:** Always explicitly coerce numeric properties using `Number()` or sanitize string values using `esc()` before interpolating them into HTML structures, regardless of the expected schema type. diff --git a/scanner/dashboard/console.html b/scanner/dashboard/console.html index 7ec262af4..c65fe87cf 100644 --- a/scanner/dashboard/console.html +++ b/scanner/dashboard/console.html @@ -121,19 +121,19 @@
${esc((s.commit||"—").slice(0,10))}${esc(f.rule_id)}${esc(f.file)}:${esc(f.line)}