T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:86
- Finding
- Excessive Probe Cache Durations Can Conceal Service and Authentication Failures<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 86–87 **Vulnerability Type**: Insecure health-check cache configuration **Risk Level**: Medium ### Vulnerable Code ```typescript const PROBE_SUCCESS_TTL_MS = 24 * 60 * 60 * 1000; // 24 hours const PROBE_ERROR_TTL_MS = 60 * 60 * 1000; // 1 hour ``` ### Technical Analysis The Skill instructs operators to cache a successful Feishu health probe for 24 hours and a failed probe for one hour. These intervals substantially reduce the freshness and reliability of health information. After a successful probe is cached, credential revocation, permission changes, account suspension, network failure, or remote API disruption may remain undetected for up to 24 hours. Similarly, a temporary API or network error may be cached for one hour, causing the system to report an unhealthy state long after connectivity has recovered. This is an availability and monitoring-integrity weakness rather than a direct privilege-escalation vulnerability. The documented usage calculation also assumes one API call per minute despite separately stating that successful results are cached for ten minutes by default. Consequently, the claimed baseline request volume and savings may overstate the benefit used to justify the risky configuration. ### Attack Path 1. The gateway successfully calls the Feishu Bot API and caches the successful result. 2. An attacker with an independent ability to revoke credentials, change application permissions, suspend the account, or disrupt connectivity causes the actual integration to fail. 3. Scheduled health checks continue using the cached successful result rather than validating the live connection. 4. Monitoring may incorrectly report the integration as healthy for up to 24 hours. 5. Operators receive delayed notification and may not begin incident response until the cache expires. For cached failures, a transient network or API error can similarly leave the integration reported a ...[truncated 691 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Use substantially shorter, configurable cache durations. A reasonable starting point is: - Successful probes: 10–30 minutes. - Failed probes: 1–5 minutes. 2. Apply shorter caching to failures than successes so temporary outages are rechecked promptly. 3. Bypass or invalidate the cache immediately after authentication failures, permission errors, configuration changes, credential rotation, or failed real API operations. 4. Add an explicit forced-probe mechanism for deployment checks and operator diagnostics. 5. Separate API-quota optimization from health monitoring. Consider lightweight local checks or adaptive probing instead of retaining status for an entire day. 6. Document the maximum detection delay introduced by each configured TTL. 7. Correct the API-usage calculations so the baseline reflects the existing successful-result cache and operators can make a risk-informed decision. 8. Add tests confirming that cached status expires correctly and that critical authentication or authorization errors invalidate cached success immediately. ]]>