T09 · Insecure Skill Coding Practices
Warning
- Location
SKILL.md:153- Finding
Insecure Persistent Storage of Private TripIt Calendar Feed URL
- Content
View full analysis
/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//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
View remediation