/wbSecure — Live Demo ()
What /wbSecure would actually surface on wb-labs right now. The candidate targets and likely attack paths below are real for the current state.
1. Live target
| Field | Live value |
|---|---|
| Most-security-relevant code | core2/packages/wb-core/src/tierEnforcement.js (gates privileged ops) |
| Cross-package auth surface | wb-core (verifier) + hypothetical consumer in wb-dataviewer |
| Known live security finding | JWT alg-denylist gap in tierEnforcement.js (per /wbAudit --profile="security" simulation in earlier files) |
| Third-party / vendored code | None obvious in core2/; would refuse without -F if requested |
| Memory rules | feedback_no_git.md (no git ops), feedback_model_selection.md (the agent for complex/auth work) — declared the agent for /wbSecure runs |
The first row is the natural target. tierEnforcement.js is the highest-value file in the workspace from a security perspective — anything that bypasses it bypasses every tier check.
2. What each input form would resolve to today
| Input | Live resolution |
|---|---|
/wbSecure core2/packages/wb-core/src/tierEnforcement.js | Standard adversarial review. Would surface alg:"none" (Path 1) plus replay considerations (Path 3) plus tier-confusion check (Path 2: not exploitable as written). |
/wbSecure --focus="auth" | Cross-package; would warn about the multi-package scope, then run. |
/wbSecure --focus="payment" | Honest "no payment code found." Suggests /wbVision if exploring future payment work. |
/wbSecure node_modules/jsonwebtoken/ | Refuse — third-party; suggests -F only if user owns the fork. |
/wbSecure "the JWT thing" | Halt — too ambiguous; lists candidate files. |
/wbSecure core2/packages/wbc-ui2-cdn/ | Permitted but cautious — memory flags this package as parked. Would scan for security issues but NOT auto-promote findings to plan. |
3. Per-flag behavior, applied live
| Flag combination | Live result |
|---|---|
| (no flag, file target) | Standard adversarial review. |
--focus="auth" | Cross-package walk; warning about scope. |
-F alone, on a vendored target | Required override; recorded in report header. |
-F on a file with literal secrets | Override accepted; secrets quoted in the report (which is itself sensitive). |
--focus="" | Halt. |
4. Pipelines
/wbSecure Live Execution Simulator
Adversarial review of tierEnforcement.js (the high-value target)
/wbSecure core2/packages/wb-core/src/tierEnforcement.js> /wbSecure core2/packages/wb-core/src/tierEnforcement.js[SYSTEM] Target: core2/packages/wb-core/src/tierEnforcement.js
[MODEL] the AI agent declared (per feedback_model_selection.md — auth work is complex)
[MODE] Adversarial — assume attacker wants to bypass tier checks.
[SCAN] Reading file...
[CONTEXT] grep for callers across wb-core and consumers...
## Threat model
The file's responsibility: given a JWT and a requested tier-gated
action, decide whether the caller's tier permits the action.
Attacker's wins:
1. Forge a token that makes them appear higher-tier than they are.
2. Bypass the check entirely.
3. Use a stale token whose tier no longer matches the user's
subscription state.
## Attack paths
### Path 1 — Algorithm confusion (`alg:"none"`)
**Severity:** High
**File:** core2/packages/wb-core/src/tierEnforcement.js (verify call site)
**Attack:** Craft a JWT with `{"alg":"none"}` header and `{"tier":"admin"}`
payload. If `jwt.verify()` is called without an `algorithms` constraint,
the verify function will accept the unsigned token.
**Status:** Likely vulnerable — the canonical /wbAudit security simulation
flagged this finding. /wbSecure confirms it from the offensive angle.
**How to verify:** Run a unit test that passes a token with alg:"none"
and asserts rejection. If the test fails (acceptance), the vulnerability
is live.
### Path 2 — Tier-string injection
**Severity:** Low (not exploitable as written)
**Reasoning:** The tier value is read as `decoded.tier` from the
parsed JSON. JS object property access doesn't have an injection
surface unless the consumer downstream concatenates `decoded.tier`
into a SQL query, a regex, or a shell command. Worth checking
consumers (Path 5).
### Path 3 — Replay after subscription downgrade
**Severity:** Medium
**Attack:** A user pays for Paid tier, gets a token with `tier:"paid"`
and `exp:` 1 hour from now. They downgrade. The token is still valid
until `exp`. They use it for the remaining hour to access Paid features.
**Status:** Standard JWT trade-off. Acceptable for short `exp` windows;
problematic for longer ones.
**Mitigation paths:** (a) shorten `exp`; (b) add server-side revocation;
(c) re-check tier server-side per request.
### Path 4 — Verifier returns truthy on parse error
**Severity:** Conditional — depends on error-handling shape
**Attack:** Pass malformed JSON. If the verifier catches the parse
error and returns a default-truthy value (e.g., empty object), downstream
code might read `decoded.tier` as undefined and accidentally pass a
free-tier check.
**Status:** Need to read the actual error-handling. If the function
re-throws or returns false, not exploitable. If it returns `{}`, exploitable.
### Path 5 — Consumer trust without re-verification
**Severity:** Medium (architectural)
**Reasoning:** Any consumer that reads `decoded.tier` directly from
a verified token inherits the verifier's flaws. If the verifier ever
has a false-positive case, every consumer is vulnerable.
**Mitigation:** Defense-in-depth (consumer re-checks signature) or
single-point-of-trust (consumers trust the verifier absolutely; verifier
is bulletproof). Current code uses the latter; that's a valid choice
but it raises the stakes on the verifier itself.
## Recommendations
1. **Path 1 fix (P0):** Constrain verify with `algorithms: ['HS256']`
(or whatever the issuer uses). Add a test that asserts alg:"none"
rejection.
2. **Path 4 confirmation (P1):** Read the actual error-handling code.
If it returns truthy on parse error, fix.
3. **Path 3 evaluation (informational):** Document the `exp` window
trade-off in code or memory.
[NO MUTATION] Report saved: reports/<date>/security/secure_tierEnforcement_<date>.md
💠 Pipeline Adversarial review of tierEnforcement.js (the high-value target)
💠 Pipeline Cross-package focus
💠 Pipeline Refuse vendored review without -F
5. What would refuse today
| Trigger | Live response |
|---|---|
/wbSecure (no target) | Halt. |
/wbSecure "the JWT thing" | Halt with disambiguation. |
/wbSecure node_modules/... | Refuse without -F. |
/wbSecure file_with_literal_secret.js | Refuse without -F. |
/wbSecure core2/packages/wbc-ui2-cdn/ | Permitted but flagged "memory: parked package; findings will not auto-promote to plan." |
/wbSecure --force-past-security (no other args) | Halt — -F is an override for an existing target/refusal, not a target itself. |
/wbSecure --focus="payment" | Honest "no payment code in workspace." Suggests /wbVision for exploration. |
| Adversarial output that would constitute step-by-step exploit instructions | Default: high-level threat model only. -F permits step-by-step (for owned code). |
The pattern: /wbSecure is the offensive complement to /wbAudit --profile="security". It produces reasoning chains, not pattern matches; refuses third-party code by default; treats -F as a recorded override; and stays inside the workspace + memory (no external CVE lookups). Run both /wbAudit -p="security" and /wbSecure for high-value code — they'll overlap on known patterns, diverge on code-specific paths, and together cover more ground than either alone.