From 17a2e256a187704077174d0481883999d9c3425a Mon Sep 17 00:00:00 2001 From: seonghobae <8172694+seonghobae@users.noreply.github.com> Date: Wed, 7 Oct 2026 19:23:26 +0000 Subject: [PATCH] =?UTF-8?q?=F0=9F=9B=A1=EF=B8=8F=20Sentinel:=20[HIGH]=20?= =?UTF-8?q?=EC=8B=AC=EA=B0=81=EB=8F=84=20=EB=B0=8F=20=EC=B9=B4=ED=85=8C?= =?UTF-8?q?=EA=B3=A0=EB=A6=AC=20=EC=B2=98=EB=A6=AC=EC=9D=98=20=ED=94=84?= =?UTF-8?q?=EB=A1=9C=ED=86=A0=ED=83=80=EC=9E=85=20=EC=98=A4=EC=97=BC=20?= =?UTF-8?q?=EB=B0=8F=20DOM=20XSS=20=EC=9C=84=ED=97=98=20=EC=88=98=EC=A0=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .jules/sentinel.md | 5 +++++ scanner/dashboard/console.html | 4 ++-- scanner/dashboard/index.html | 6 +++--- tests/test_dashboard_status_contracts.py | 2 +- 4 files changed, 11 insertions(+), 6 deletions(-) diff --git a/.jules/sentinel.md b/.jules/sentinel.md index 1600d4323..de34e849b 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-08-05 - [DOM XSS and Prototype Pollution via Object literals in Dashboard] +**Vulnerability:** DOM XSS and Prototype Pollution via unescaped dictionary lookup keys like `severity` and `category` injected into maps configured as `{}`. +**Learning:** Using `{}` constructs a JavaScript object that inherits from `Object.prototype`. If an attacker supplies keys like `__proto__` or `constructor` via user-controlled strings (e.g. `findings.json`), property lookups (like `SEV[f.severity]`) will access native prototype properties instead of undefined map entries. Coercing these native functions to strings results in outputs like `function Object() { [native code] }`, breaking rendering logic, causing DOM XSS if injected into `innerHTML` sinks, and polluting application state. Using `.toUpperCase()` does not neutralize this, as properties like `__PROTO__` may still cause undefined behaviors or prototype interference in certain engines, and `constructor` remains dangerous regardless of casing. +**Prevention:** Always create dictionaries designed to store arbitrary user-provided keys using `Object.create(null)` to ensure a null prototype. Additionally, when using user input as a key to look up statically defined safe values, explicitly validate the key exists directly on the object using `Object.hasOwn(obj, key)` rather than relying on loose lookups or the `in` operator, which traverses the prototype chain. diff --git a/scanner/dashboard/console.html b/scanner/dashboard/console.html index 7ec262af4..627fc4dbd 100644 --- a/scanner/dashboard/console.html +++ b/scanner/dashboard/console.html @@ -76,7 +76,7 @@

AppGuardrail Console