T09 · Insecure Skill Coding Practices
- Location
SKILL.md:103- Finding
Consequential reservation changes lack an enforced confirmation gate
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:103-109; supporting request procedures inreferences/opentable-fpx-requests.md:16-19,references/opentable-fpx-requests.md:244-285, andreferences/opentable-fpx-requests.md:322-349
Vulnerability Type: Unconfirmed authenticated account mutation
Risk Level: MediumVulnerable instruction:
markdown - **Booking, modifying, and cancelling are real actions with no confirm-gate here.** The MCP's `opentable_book`/`opentable_modify`/ `opentable_cancel` tools ask the user to confirm first (a prompt, or a preview + single-use `confirmToken`) plus a mandatory preview step; raw `fpx` calls have none of that — a `make-reservation` POST commits immediately. Fetch `/booking/details` and read the cancellation policy first (§5 of the reference) before calling it.Supporting commit procedure:
markdown ## 6. Book — step 2: commit (`/dapi/booking/make-reservation`) Plain JSON POST (not a persisted query). Consumes the `slotLockId` from §5, plus your own profile fields (from §4's `.header.userProfile` — `mobilePhoneNumber.number` with the country code stripped) and a fresh `correlationId` (any UUID). **This makes a real reservation — no dry-run.**Technical Analysis
The Skill intentionally replaces OpenTable MCP operations that use a prompt or a preview-bound, single-use
confirmTokenwith directfpxrequests. These requests execute using the session of a paired, signed-in OpenTable browser tab.The documented preview retrieves booking details and advises the Agent to inspect cancellation and payment conditions, but it does not technically enforce fresh user approval. The commit endpoint accepts the prepared reservation data directly, while the cancellation procedure similarly submits an authenticated mutation without a confirmation token or interactive gate.
This creates a reachable separation-of-intent flaw: once the ...[truncated 1984 chars]
- Remediation
View remediation
Remediation Suggestions
Introduce a local write-operation wrapper and prohibit direct mutation calls from the Skill workflow.
- Generate a preview containing the exact action, restaurant, date and time, party size, seating area, cancellation policy, payment requirements, and any expected fee.
- Require fresh, explicit user approval after presenting that preview.
- Issue a short-lived, single-use confirmation token bound cryptographically to the action type, account context, target reservation, and complete parameter set.
- Reject booking, modification, cancellation, and favorite mutations unless the request includes a valid token.
- Invalidate the token after one use and whenever any bound parameter changes.
- Keep read-only operations as the default and expose mutation operations only through the confirmation-enforcing wrapper.
- Add a dry-run mode that emits the intended request without transmitting it.
- For payment-backed or fee-bearing reservations, require a separate confirmation that explicitly states the applicable financial terms.
- Update
references/opentable-fpx-requests.mdso raw mutation examples cannot be treated as directly runnable Agent procedures without the wrapper.
