T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:153
- Finding
- Insecure Persistent Storage of Private TripIt Calendar Feed URL<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:153-164` **Vulnerability Type**: Sensitive bearer URL stored without security controls **Risk Level**: Medium ### Vulnerable Documentation ```markdown 1. The user provides their TripIt iCal URL (found at **TripIt → Settings → Calendar Feed**), e.g.: `https://www.tripit.com/feed/ical/private/<hash>/tripit.ics` 2. Fetch the feed and look for the newly added item (match on confirmation number, dates, or summary text) 3. If the item doesn't appear after ~60 seconds, check: - Was the sender email linked to the TripIt account? - Was the email sent as plain text (not HTML)? - Were all required fields present? ```bash # Fetch and search the feed for a confirmation number curl -s "https://www.tripit.com/feed/ical/private/<hash>/tripit.ics" \ | grep -A5 "UA1234X" ``` **Tip:** Store the user's iCal feed URL so you can verify future sends without asking again. ``` ### Technical Analysis The private TripIt iCal URL contains a secret hash in its path and functions like a bearer credential: possession of the complete URL may be sufficient to retrieve the associated travel calendar without separate authentication. The Skill explicitly recommends storing this URL for future use but does not specify: - Explicit user consent for persistent retention - Use of an encrypted credential or secret store - Redaction from logs, transcripts, and diagnostic output - A retention period or deletion mechanism - Access controls limiting which sessions or tools can retrieve it - Rotation or revocation procedures after suspected disclosure Travel calendars can contain highly sensitive information, including travel dates, flight routes, accommodation details, and the periods during which a user may be away from home. Treating the feed URL as ordinary reusable state can therefore expose both personal data and physical-location information. ### Attack Path 1. The user supplies their private TripIt iCal feed UR ...[truncated 1230 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Do not store the private feed URL by default. Request it only when verification is required. 2. Obtain explicit informed consent before retaining the URL across sessions. 3. Store the URL only in an approved encrypted secret store, not in ordinary Agent memory, transcripts, configuration files, or logs. 4. Treat the entire URL as a credential and redact the private path and hash from all output and diagnostic messages. 5. Restrict access to the minimum Agent identity and tools that require calendar verification. 6. Define a limited retention period and provide the user with a way to inspect and delete the stored credential. 7. Never send the private feed URL to unrelated services, tools, or model contexts. 8. Advise users to regenerate the TripIt calendar feed URL after suspected exposure. 9. Replace the existing recommendation with guidance such as: ```markdown Do not persist the private iCal feed URL by default. If the user explicitly requests future automatic verification, store it only in an approved encrypted secret store, redact it from logs and responses, and provide a deletion option. Treat the URL as a bearer credential. ``` ]]>