MCP Time Server Node

# Security Input Limits - Verified Behavior ## Date: 2025-07-28 ## Summary Research to determine appropriate input length limits for security hardening of the MCP Time Server. ## Test Environment - Node.js 18+ - date-fns: ^4.1.0 - date-fns-tz: ^3.2.0 ## Key Findings ### 1. Memory Impact - String inputs up to 1MB have minimal memory impact (~1MB heap usage) - JSON.stringify performance is acceptable up to 100KB (0.80ms) - Arrays of 10,000 items only use ~200KB additional memory ### 2. Library Behavior - `parseISO()` safely handles malformed inputs without crashes - Large strings (1000+ chars) return invalid dates quickly (< 1ms) - Null bytes, Unicode, and RTL characters are handled safely ### 3. Timezone Validation - `getTimezoneOffset()` safely rejects invalid timezones - Path traversal attempts (`../../../etc`) are rejected - Null byte injection attempts fail validation - Performance remains under 1ms even with 1000 char inputs ### 4. Cache Key Concerns - Direct concatenation with user input creates unbounded key lengths - 1000 char timezone = 1020 char cache key (memory waste) - SHA-256 hash provides consistent 16-char keys regardless of input ## Security Recommendations ### Input Length Limits ```typescript export const LIMITS = { MAX_STRING_LENGTH: 1000, // General string inputs MAX_TIMEZONE_LENGTH: 100, // IANA timezones are typically < 30 chars MAX_DATE_STRING_LENGTH: 100, // ISO dates are ~25 chars max MAX_FORMAT_LENGTH: 200, // Format strings rarely exceed 50 chars MAX_ARRAY_LENGTH: 365, // One year of daily entries }; ``` ### Rationale 1. **1000 chars** - Provides huge safety margin while preventing abuse 2. **100 chars for timezone** - Longest valid IANA timezone is ~30 chars 3. **100 chars for dates** - ISO 8601 dates with timezone are ~35 chars max 4. **200 chars for formats** - Complex formats rarely exceed 50 chars 5. **365 array items** - Covers full year of holidays/dates ### Cache Key Sanitization ```typescript import { createHash } from 'crypto'; export function sanitizeCacheKey(key: string): string { // Create predictable, fixed-length cache keys return createHash('sha256') .update(key) .digest('hex') .substring(0, 16); } ``` Benefits: - Fixed 16-char length regardless of input - Prevents memory exhaustion via long keys - Maintains cache functionality - No collision risk with SHA-256 ## Attack Scenarios Tested ### 1. Memory Exhaustion - ❌ Sending 1MB strings - Minimal impact, but should limit - ❌ Sending 10K item arrays - Only 200KB impact - ✅ Limits prevent accumulation of large inputs ### 2. CPU Exhaustion - ❌ Large string parsing - All operations < 1ms - ❌ JSON.stringify of 100KB - Only 0.80ms - ✅ No exponential performance degradation ### 3. Injection Attacks - ✅ Null bytes handled safely - ✅ Unicode/emoji handled safely - ✅ Path traversal rejected by timezone validation - ✅ RTL override characters don't affect parsing ### 4. Cache Poisoning - ❌ Long cache keys could exhaust memory over time - ✅ Hash-based keys prevent this attack vector ## Implementation Priority 1. Add input length validation (prevents most attacks) 2. Implement cache key hashing (prevents memory issues) 3. Add comprehensive test suite 4. Monitor for edge cases in production ## References - OWASP Input Validation Cheat Sheet - Node.js Security Best Practices - MCP Security Considerations (when available)