bridgebench 3.1.0-alpha.0 → 3.1.0-alpha.2

package/tasks/security/public/authz-object-scope-idor.yaml

@@ -0,0 +1,228 @@
+id: authz-object-scope-idor
+version: 1.0.0
+category: security
+cluster: authz-boundary
+difficulty: expert
+title: Vellum Multi-Tenant Document API — Object-Scope Isolation Analysis
+summary: >-
+  In the multi-tenant "Vellum" document API, every by-id read of an org-owned row
+  must carry an org_id predicate. Several by-id endpoints look suspicious; some are
+  scoped in a service layer, some are cross-org by design. Exactly one is a real
+  cross-tenant IDOR. Classify five endpoints, name the single defect, and locate
+  the fix — using only the artifacts.
+prompt: |
+  You are reviewing tenant isolation on "Vellum," a multi-tenant document API.
+  Rows in documents/folders belong to one organization via an org_id column, and
+  the caller's organization arrives as ctx.orgId. You are given seven artifacts:
+  documents-controller, folders-controller, document-service, shares-service,
+  db-queries, tenancy-spec, and design-note.
+
+  Answer each item using ONLY the supplied artifacts. Cite the artifact id(s) you
+  rely on for every claim. If something is not defined/reachable/exploitable in
+  the artifacts, say so explicitly. Do NOT write exploit code, requests, or
+  enumeration payloads — this is an analysis-only task.
+
+  For items 1–5, classify each endpoint as exactly one of: PROPERLY-SCOPED (tenant
+  isolation enforced), CROSS-TENANT IDOR (an org-owned row is loaded without an
+  org predicate), or INTENDED CROSS-ORG / GLOBAL (unscoped access is by design).
+  Justify each answer by citing the query's actual WHERE predicate (db-queries),
+  the code path that builds it, and the relevant tenancy rule or design decision.
+
+  1. GET   /documents/:id     (DocumentsController.getDocument)
+  2. GET   /folders/:id       (FoldersController.getFolder)
+  3. GET   /shares/:token     (SharesService.resolveShare)
+  4. GET   /templates/:id     (template catalog read)
+  5. PATCH /documents/:id     (DocumentsController.updateDocument) — is this a
+     broken-tenant-isolation or a mass-assignment defect, or neither?
+
+  6. Exactly one endpoint is a genuine cross-tenant IDOR (broken object-level
+     authorization). Name that single endpoint and state the precondition an
+     attacker needs for it to be exploitable. Ground the claim in the query
+     predicate and the tenancy rule it violates.
+
+  7. State where and how to fix the IDOR from item 6 — the exact predicate to add
+     and the layer it belongs in — and explain why a fix at that layer is correct
+     while a controller-level check is not the right place.
+artifacts:
+  - id: documents-controller
+    type: code
+    label: vellum-api/src/documents/documents.controller.ts
+    content: |
+      // Every route requires a valid session (global AuthGuard) and receives the
+      // caller's tenant context as `ctx` (ctx.orgId = the caller's organization).
+      // This file lists every route on the /documents controller.
+
+      @Controller('documents')
+      @UseGuards(AuthGuard)
+      export class DocumentsController {
+        // Read a single document by id. For latency this reads through the
+        // repository DIRECTLY rather than DocumentService; the SQL it runs is
+        // db-queries q_get_document.
+        @Get(':id')
+        getDocument(@Ctx() ctx: TenantCtx, @Param('id') id: string) {
+          return this.documentsRepo.findById(id);
+        }
+
+        // List the caller's documents (through DocumentService).
+        @Get()
+        listDocuments(@Ctx() ctx: TenantCtx) {
+          return this.documentService.listDocuments(ctx);
+        }
+
+        // Update a document. The body is bound to UpdateDocumentDto, which is
+        // `strict`: only `title` and `body` are accepted; unknown keys (including
+        // org_id) are stripped and rejected. Persists via DocumentService.
+        @Patch(':id')
+        updateDocument(
+          @Ctx() ctx: TenantCtx,
+          @Param('id') id: string,
+          @Body() dto: UpdateDocumentDto,
+        ) {
+          return this.documentService.updateDocument(ctx, id, dto);
+        }
+
+        // Soft-delete a document (through DocumentService).
+        @Delete(':id')
+        deleteDocument(@Ctx() ctx: TenantCtx, @Param('id') id: string) {
+          return this.documentService.deleteDocument(ctx, id);
+        }
+      }
+  - id: folders-controller
+    type: code
+    label: vellum-api/src/folders/folders.controller.ts
+    content: |
+      // This file lists every route on the /folders controller. Note the
+      // controller does not itself add any tenant filter — folder scoping lives in
+      // DocumentService (see document-service).
+
+      @Controller('folders')
+      @UseGuards(AuthGuard)
+      export class FoldersController {
+        @Get(':id')
+        getFolder(@Ctx() ctx: TenantCtx, @Param('id') id: string) {
+          return this.documentService.getFolder(ctx, id);
+        }
+
+        @Get(':id/documents')
+        listFolderDocuments(@Ctx() ctx: TenantCtx, @Param('id') id: string) {
+          return this.documentService.listFolderDocuments(ctx, id);
+        }
+      }
+  - id: document-service
+    type: code
+    label: vellum-api/src/documents/document.service.ts
+    content: |
+      // Tenant scoping for folder reads, list reads, updates, and deletes lives
+      // HERE: each method injects ctx.orgId into the query it builds. The raw SQL
+      // for each is catalogued in db-queries.
+
+      @Injectable()
+      export class DocumentService {
+        getFolder(ctx: TenantCtx, id: string) {
+          // q_get_folder: WHERE id = :id AND org_id = :orgId
+          return this.foldersRepo.findScoped(id, ctx.orgId);
+        }
+
+        listFolderDocuments(ctx: TenantCtx, folderId: string) {
+          // q_list_folder_docs: WHERE folder_id = :id AND org_id = :orgId
+          return this.documentsRepo.findByFolderScoped(folderId, ctx.orgId);
+        }
+
+        listDocuments(ctx: TenantCtx) {
+          // q_list_documents: WHERE org_id = :orgId AND deleted_at IS NULL
+          return this.documentsRepo.findAllScoped(ctx.orgId);
+        }
+
+        updateDocument(ctx: TenantCtx, id: string, dto: UpdateDocumentDto) {
+          // q_update_document: WHERE id = :id AND org_id = :orgId
+          return this.documentsRepo.updateScoped(id, ctx.orgId, dto);
+        }
+
+        deleteDocument(ctx: TenantCtx, id: string) {
+          // q_delete_document: WHERE id = :id AND org_id = :orgId
+          return this.documentsRepo.softDeleteScoped(id, ctx.orgId);
+        }
+
+        // NOTE: single-document-by-id reads are NOT served here.
+        // DocumentsController.getDocument calls documentsRepo.findById(id)
+        // directly (see documents-controller), bypassing this scoping layer.
+      }
+  - id: shares-service
+    type: code
+    label: vellum-api/src/shares/shares.service.ts
+    content: |
+      // Public share links. A document owner mints an unguessable 256-bit token;
+      // anyone holding the token — INCLUDING users in other organizations — may
+      // read the shared document. This cross-org access is intentional (design-note).
+      // GET /shares/:token routes straight to resolveShare().
+
+      @Injectable()
+      export class SharesService {
+        // q_get_share: WHERE share_token = :token AND revoked_at IS NULL
+        resolveShare(token: string) {
+          return this.sharesRepo.findByToken(token);
+        }
+      }
+  - id: db-queries
+    type: table
+    label: Vellum data-access catalog (per-endpoint WHERE predicates — complete)
+    content: |
+      The WHERE predicate of every by-id / by-token read and write in Vellum. This
+      catalog is COMPLETE: every endpoint that loads or mutates a row by an
+      identifier appears here with the EXACT predicate its query uses. If a
+      predicate is not shown for an endpoint, that endpoint does not exist.
+
+      endpoint                     | query id           | table     | WHERE predicate
+      -----------------------------|--------------------|-----------|----------------------------------------------
+      GET    /documents/:id        | q_get_document     | documents | id = :id
+      GET    /documents            | q_list_documents   | documents | org_id = :orgId AND deleted_at IS NULL
+      PATCH  /documents/:id        | q_update_document  | documents | id = :id AND org_id = :orgId
+      DELETE /documents/:id        | q_delete_document  | documents | id = :id AND org_id = :orgId
+      GET    /folders/:id          | q_get_folder       | folders   | id = :id AND org_id = :orgId
+      GET    /folders/:id/documents| q_list_folder_docs | documents | folder_id = :id AND org_id = :orgId
+      GET    /shares/:token        | q_get_share        | shares    | share_token = :token AND revoked_at IS NULL
+      GET    /templates/:id        | q_get_template     | templates | id = :id
+  - id: tenancy-spec
+    type: spec
+    label: Vellum multi-tenancy rules (authoritative)
+    content: |
+      Authoritative tenant-isolation rules.
+
+      1. Every row in `documents`, `folders`, and `document_versions` belongs to
+         exactly one organization via its `org_id` column. A caller in org A must
+         never read, update, or delete a row whose org_id != A.
+
+      2. Therefore every query that loads such a row by its primary key MUST include
+         `AND org_id = :orgId`, where :orgId is the caller's organization from the
+         tenant context. A by-id read of an org-owned row that omits this predicate
+         is a cross-tenant isolation defect (IDOR): document ids are UUIDv7 and
+         appear in URLs, export bundles, and webhook payloads, so an id belonging to
+         org B is readily observable by a user in org A.
+
+      3. EXCEPTIONS — rows that are intentionally NOT org-scoped:
+         - `templates`: a single GLOBAL catalog shared by all organizations.
+           Template rows have no org_id column; GET /templates/:id is global by
+           design and correctly omits an org predicate.
+         - Share links (`shares`): access is granted by possession of an unguessable
+           256-bit `share_token`, not by org membership. A cross-org read via a
+           valid token is an intended product feature (see design-note).
+
+      4. Write endpoints MUST bind the request body to a strict DTO that whitelists
+         updatable columns. `org_id` is never an updatable column.
+  - id: design-note
+    type: note
+    label: Vellum design notes — cross-org sharing and the update path
+    content: |
+      Share links are meant to cross tenant boundaries. When a document owner
+      creates a share we mint a 256-bit random token; anyone holding the link can
+      read that one document regardless of their organization. Enumeration is not a
+      concern: the token space is unguessable and resolveShare() looks up STRICTLY
+      by token (db-queries q_get_share), returning nothing for an unknown or revoked
+      token. This is a feature, not a leak.
+
+      The update path (PATCH /documents/:id) once accepted a raw body, which looked
+      like a mass-assignment risk. It now binds to UpdateDocumentDto, which
+      whitelists only `title` and `body`; unknown fields (including org_id) are
+      stripped and rejected. Combined with the org predicate on q_update_document
+      (id AND org_id), a caller can only ever update documents in their own org.
+tags: [authz, idor, multi-tenant, tenant-isolation, authz-boundary, security]

package/tasks/security/public/patch-mass-assignment-privesc.yaml

@@ -0,0 +1,226 @@
+id: patch-mass-assignment-privesc
+version: 1.0.0
+category: security
+cluster: patch-verification
+difficulty: expert
+title: Wicket Accounts — Verifying Five Candidate Mass-Assignment Privilege-Escalation Fixes
+summary: >-
+  The Wicket accounts profile-update handler trusts `body.role` AND spreads nested
+  `body.metadata` onto the account row, allowing self privilege escalation. Five
+  competing candidate patches are submitted. Decide which actually close BOTH write
+  paths and which are incomplete, cosmetic, or only provable by reading the
+  editable-fields allowlist — analysis only.
+prompt: |
+  You are reviewing candidate fixes for a reported mass-assignment privilege-escalation
+  finding in the "Wicket" accounts service. The handler PATCH /accounts/me lets a caller
+  update their own profile, but it writes `req.body.role` directly onto the account row
+  AND spreads `req.body.metadata` onto the same row, so a role supplied either directly
+  or nested under metadata reaches the privileged `role` column. Five engineers submitted
+  competing patches (A, B, C, D, E); exactly one will be merged.
+
+  You are given six artifacts: update-handler (the vulnerable handler), editable-fields
+  (the allowlist constant defining which columns a self-service update may write),
+  patches-abc (candidate patches A, B, C), patches-de (candidate patches D, E), role-model
+  (the authoritative spec on how `role` is stored and every position that can write it),
+  and vuln-report (the finding).
+
+  Answer each deliverable using ONLY the supplied artifacts. Cite the artifact id(s) you
+  rely on for every claim. If a fact needed to judge a patch lives in another artifact,
+  OPEN that artifact and cite it — do not guess. This is analysis only: reason about which
+  write positions each patch neutralizes; do NOT write exploit requests or payloads.
+
+  Definitions you must use:
+  - role-model is authoritative: it enumerates EXACTLY the code positions in this handler
+    that can write `user.role`. A patch CLOSES the finding only if it neutralizes BOTH
+    declared write positions.
+  - editable-fields is the source of truth for which fields a profile update may write.
+  - A patch DOES-NOT-CLOSE if any declared write position for `role` still reaches the
+    row, or if it changes a layer (e.g. the response) that does not affect the write.
+
+  Deliverables:
+
+  1. Patch A (patches-abc): verdict CLOSES or DOES-NOT-CLOSE, with the specific reason.
+     Which declared write positions does it neutralize?
+
+  2. Patch B (patches-abc): verdict and the specific gap. Does it neutralize BOTH declared
+     write positions, or does one path still reach `role`?
+
+  3. Patch C (patches-abc): verdict and the specific gap. Consider what values survive its
+     check, using role-model.
+
+  4. Patch D (patches-de): verdict. Patch D uses `Object.assign(user, pick(req.body,
+     EDITABLE_FIELDS))`. State whether D is safe, unsafe, or unverifiable from the
+     artifacts, and name the EXACT artifact you must open to decide. Justify with what
+     that artifact contains.
+
+  5. Patch E (patches-de): verdict and the specific gap. Which layer does it change, and
+     does that layer affect the write path?
+
+  6. Recommend which single patch to merge and state any residual work still required
+     after merging it (for example, a declared write position a different patch would have
+     left open). Justify from role-model and editable-fields.
+artifacts:
+  - id: update-handler
+    type: code
+    label: Wicket profile-update handler (vulnerable original)
+    content: |
+      // wicket/accounts/update-profile.ts — PATCH /accounts/me (Wicket accounts service).
+      // Self-service profile update for the logged-in caller.
+
+      export async function updateProfile(req: Request, res: Response) {
+        const user = await accounts.findById(req.session.userId);
+
+        // Apply the caller's changes.
+        user.displayName = req.body.displayName ?? user.displayName;
+        user.role = req.body.role ?? user.role;        // WRITE POSITION 1: direct role assign
+        Object.assign(user, req.body.metadata ?? {});  // WRITE POSITION 2: spreads nested metadata
+
+        await accounts.save(user);
+        return res.json({ id: user.id, displayName: user.displayName, role: user.role });
+      }
+  - id: editable-fields
+    type: code
+    label: EDITABLE_FIELDS allowlist constant (source of truth)
+    content: |
+      // wicket/accounts/editable-fields.ts
+      // Single source of truth for which account columns a self-service profile update
+      // may write. Anything NOT listed here is server-controlled and must never be set
+      // from request input.
+
+      export const EDITABLE_FIELDS = [
+        'displayName',
+        'bio',
+        'avatarUrl',
+        'locale',
+      ] as const;
+
+      // NOTE: 'role' is intentionally EXCLUDED — role changes go through the admin grant
+      // flow only (see role-model). 'metadata' is also excluded: it is not a persisted
+      // column, so it is never a valid write target for a profile update.
+  - id: role-model
+    type: spec
+    label: Wicket role model — authoritative role storage and write-position inventory
+    content: |
+      Wicket role model — AUTHORITATIVE.
+
+      Storage:
+        - Every account row has a single top-level column `role` (string). Its legal
+          values are exactly ROLE_ENUM = ['member', 'billing', 'support', 'admin'].
+        - `role` is PRIVILEGED and server-controlled. In the self-service profile-update
+          path it must NEVER be writable from request input.
+        - The ONLY legitimate way to change a role is the admin grant flow
+          (POST /admin/roles), which is out of scope for updateProfile.
+
+      Why enum validation is insufficient:
+        - All four ROLE_ENUM values are syntactically valid role names. 'admin' is the
+          privileged one. Validating a submitted role against ROLE_ENUM therefore does NOT
+          prevent escalation — 'admin' passes the enum check and is still a self-assigned
+          privileged role.
+
+      Write-position inventory for updateProfile (EXHAUSTIVE):
+        - `user.role` can be written by EXACTLY TWO code positions in this handler:
+            WP1 — a direct assignment `user.role = <request input>`.
+            WP2 — any `Object.assign(user, X)` / object spread where X carries a `role`
+                  key. In the original handler X is `req.body.metadata`, so a caller can
+                  set `role` nested under `metadata` and reach the same column.
+        - There are NO other code positions in this handler that can write `role`.
+        - A fix CLOSES the mass-assignment finding ONLY if it neutralizes BOTH WP1 and WP2.
+        - `metadata` is not a persisted column and is not in EDITABLE_FIELDS; spreading it
+          onto the account row is itself the nested-assignment bug (WP2).
+  - id: patches-abc
+    type: diff
+    label: Candidate patches A, B, C (mutually exclusive alternatives)
+    content: |
+      Three competing candidate patches. Exactly ONE of A/B/C is applied — they are
+      alternatives, not stacked.
+
+      === Patch A: strict allowlist DTO (role and metadata rejected) ===
+      --- a/wicket/accounts/update-profile.ts
+      +++ b/wicket/accounts/update-profile.ts
+      @@ handler body
+      -  user.displayName = req.body.displayName ?? user.displayName;
+      -  user.role = req.body.role ?? user.role;
+      -  Object.assign(user, req.body.metadata ?? {});
+      +  // validateProfileDto returns ONLY { displayName?, bio?, avatarUrl?, locale? };
+      +  // it strips/rejects any other key, including `role` and `metadata`.
+      +  const dto = validateProfileDto(req.body);
+      +  if (dto.displayName !== undefined) user.displayName = dto.displayName;
+      +  if (dto.bio !== undefined) user.bio = dto.bio;
+      +  if (dto.avatarUrl !== undefined) user.avatarUrl = dto.avatarUrl;
+      +  if (dto.locale !== undefined) user.locale = dto.locale;
+
+      === Patch B: reject a direct body.role ===
+      --- a/wicket/accounts/update-profile.ts
+      +++ b/wicket/accounts/update-profile.ts
+      @@ handler body
+      +  if (req.body.role !== undefined) {
+      +    return res.status(400).json({ error: 'role is not editable' });
+      +  }
+         user.displayName = req.body.displayName ?? user.displayName;
+      -  user.role = req.body.role ?? user.role;
+      +  // (direct role assignment removed)
+         Object.assign(user, req.body.metadata ?? {});   // metadata spread KEPT
+
+      === Patch C: validate body.role against the role enum ===
+      --- a/wicket/accounts/update-profile.ts
+      +++ b/wicket/accounts/update-profile.ts
+      @@ handler body
+         user.displayName = req.body.displayName ?? user.displayName;
+      -  user.role = req.body.role ?? user.role;
+      +  if (req.body.role !== undefined) {
+      +    if (!ROLE_ENUM.includes(req.body.role)) {
+      +      return res.status(400).json({ error: 'invalid role' });
+      +    }
+      +    user.role = req.body.role;   // accepts ANY valid role name
+      +  }
+         Object.assign(user, req.body.metadata ?? {});   // metadata spread KEPT
+  - id: patches-de
+    type: diff
+    label: Candidate patches D, E (mutually exclusive alternatives)
+    content: |
+      Two more competing candidate patches — alternatives to A/B/C, not stacked with them.
+
+      === Patch D: pick() over the EDITABLE_FIELDS allowlist ===
+      --- a/wicket/accounts/update-profile.ts
+      +++ b/wicket/accounts/update-profile.ts
+      @@ imports
+      +import { EDITABLE_FIELDS } from './editable-fields';
+      @@ handler body
+      -  user.displayName = req.body.displayName ?? user.displayName;
+      -  user.role = req.body.role ?? user.role;
+      -  Object.assign(user, req.body.metadata ?? {});
+      +  // pick() keeps ONLY keys present in EDITABLE_FIELDS; every other key of req.body
+      +  // (role, metadata, and anything nested) is dropped before it can touch the row.
+      +  Object.assign(user, pick(req.body, EDITABLE_FIELDS));
+
+      === Patch E: drop role from the response body ===
+      --- a/wicket/accounts/update-profile.ts
+      +++ b/wicket/accounts/update-profile.ts
+      @@ handler body
+         user.displayName = req.body.displayName ?? user.displayName;
+         user.role = req.body.role ?? user.role;         // WRITE POSITION 1 unchanged
+         Object.assign(user, req.body.metadata ?? {});   // WRITE POSITION 2 unchanged
+
+         await accounts.save(user);
+      -  return res.json({ id: user.id, displayName: user.displayName, role: user.role });
+      +  return res.json({ id: user.id, displayName: user.displayName }); // role not echoed
+  - id: vuln-report
+    type: note
+    label: Wicket security advisory WICKET-2026-014 (internal)
+    content: |
+      Advisory WICKET-2026-014 (internal, fictional).
+
+      A reporter found that PATCH /accounts/me lets a caller escalate their OWN role. Two
+      observations:
+        (1) the handler copies `req.body.role` straight onto the account row (a direct
+            write position);
+        (2) the handler ALSO spreads `req.body.metadata` onto the row, so a `role` nested
+            under metadata reaches the same column (a second, nested write position).
+
+      Request to the reviewer: verify that each candidate patch actually closes BOTH write
+      positions, not just the obvious direct one. Authoritative details on how `role` is
+      stored and the exhaustive list of write positions are in role-model; the
+      editable-fields constant is the source of truth for what a profile update may write.
+      To judge a patch that relies on that constant, OPEN editable-fields and confirm what
+      it contains rather than assuming.
+tags: [security, patch-verification, mass-assignment, privilege-escalation, allowlist]