SITCON 學生計算機年會 tickets webhook management routes authorize one event ID but operate on path eventId - HITCON ZeroDay

Summary

The public sitcon-tw/tickets backend has webhook management routes under:

/api/admin/events/:eventId/webhook

These routes use requireEventAccess. That middleware authorizes event-scoped admins by checking:

query.eventId || params.id || body.eventId

It does not check params.eventId, which is the path parameter used by the webhook handlers.

The source therefore exposes two mismatch patterns:

• POST /api/admin/events/:eventId/webhook can be authorized by body.eventId, while the handler creates the webhook for path eventId.
• GET, PUT, and DELETE /api/admin/events/:eventId/webhook can be authorized by ?eventId=<owned-event>, while the handlers read, update, or delete the webhook for path eventId.

If deployed as shown in source, an event-scoped organizer may be able to read, create, modify, or delete webhook configuration for an unrelated event.

Source evidence

• backend/middleware/auth.ts reads query?.eventId || params?.id || body?.eventId.
• backend/routes/admin/webhooks.ts protects webhook get/create/update/delete routes with preHandler: [requireEventAccess].
• backend/routes/admin/webhooks.ts destructures eventId from request.params.
• backend/routes/admin/webhooks.ts uses path eventId for findUnique, event lookup, existing-webhook checks, create, update, and delete.
• types/src/webhook.ts defines WebhookEndpointCreateRequestSchema with eventId, allowing create authorization to be satisfied by body eventId.
• types/src/webhook.ts defines WebhookEndpointUpdateRequestSchema without eventId, so update can instead be authorized through query eventId.
• backend/schemas.ts defines get/update/delete webhook route schemas with path params only and no querystring schema for event authorization.
• backend/utils/webhook.ts shows webhook notifications include registration email, attendee email/name, form data, ticket info, and event info.

Local-only reproduction

I validated the control flow using local static modeling only:

python3 findings/20260603-1423-hitcon-sitcon-webhook-create-eventid-mismatch/local-repro.py

Result:

{
  "observed_candidate_behavior": true,
  "network_requests": 0,
  "validation_mode": "LOCAL_SOURCE_STATIC_MODEL"
}

Modeled requests:

POST /api/admin/events/victim-event/webhook
body.eventId = owned-event

GET /api/admin/events/victim-event/webhook?eventId=owned-event
PUT /api/admin/events/victim-event/webhook?eventId=owned-event
DELETE /api/admin/events/victim-event/webhook?eventId=owned-event

eventAdmin permissions = [owned-event]
guard authorized event = owned-event
handler target event = victim-event

Impact

Unauthorized webhook creation or modification can route future registration or cancellation notifications for another event to an attacker-controlled HTTPS endpoint. Unauthorized read/delete can disclose webhook configuration metadata or disrupt webhook delivery for another event.

Based on the public source, webhook payloads can include registration IDs, registration email, attendee email/name, form data, event metadata, and ticket metadata.

This report is intentionally conservative: I validated public source and local control flow only. I did not prove live SITCON production exploitability.

Safety boundary

This report is based on public source and local-only analysis. I did not log in to SITCON, request SITCON production/private endpoints, create/update/delete/test/receive a real webhook, access real event/registration/ticket/email/form data, use scanners/fuzzing/DoS, contact SITCON, publish an issue, or open a PR.