T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:200
- Finding
- Product Access Recommended Before Email Ownership Verification## Vulnerability Details **File Location**: `SKILL.md`, line 200 **Vulnerability Type**: Authentication and identity-verification weakness **Risk Level**: Medium **Vulnerable Code Snippet**: ```markdown - No email confirmation gate (or send confirm in background, let them in immediately) ``` ### Technical Analysis The skill recommends allowing a newly registered user to enter the product before confirming ownership of the supplied email address. This creates an insecure onboarding pattern if the resulting session can perform identity-sensitive operations. Email verification commonly establishes control over an account identifier used for tenant membership, invitations, password recovery, notifications, trial eligibility, and other authorization decisions. A background confirmation message does not mitigate the issue if the unverified session receives normal account privileges before verification is completed. Exploitability depends on how a product implements this recommendation. The risk is material when the application treats an unverified email address as trusted or permits privileged actions from a provisional account. ### Attack Path 1. An attacker starts registration using an email address they do not control. 2. Following the recommended flow, the application creates a session and grants immediate product access without requiring email confirmation. 3. The attacker uses any functionality available to the unverified session, potentially including creating resources, consuming trial entitlements, initiating invitations, or accessing tenant flows that rely on the claimed email domain or address. 4. If downstream authorization logic assumes the email is verified, the attacker may obtain access or benefits associated with an identity they have not proven they control. 5. The actual email owner may also receive unsolicited account messages or encounter account-registration conflicts. ### Impact Assessment The dire ...[truncated 759 chars]
- Remediation
- ## Remediation Suggestions Replace the unconditional recommendation with a restricted provisional-access design: 1. Require email verification before granting normal account privileges or performing identity-sensitive actions. 2. If immediate onboarding is necessary, issue a short-lived provisional session with explicitly limited permissions. 3. Before verification, block tenant access, invitations, billing, exports, external integrations, password recovery changes, API token creation, and access based on email address or domain. 4. Clearly mark the account as unverified in the identity and authorization layers; do not rely only on a user-interface restriction. 5. Require successful verification before converting provisional resources or trial benefits into a normal account. 6. Rate-limit registration and verification-message delivery to prevent spam and trial abuse. 7. Expire and delete abandoned provisional accounts after a defined period. 8. Add automated authorization tests confirming that unverified users cannot perform sensitive operations. A safer replacement instruction would be: ```markdown - Allow immediate access only through a restricted provisional session. Require email verification before tenant access, invitations, billing, integrations, exports, API credentials, recovery changes, or any operation that trusts the claimed email identity. ```