swagger-tools/docs/tasks/archive/security-hardening-task.md

openproject	base-branch
362	dev

Task: Security Hardening - Address ReDoS, Path Traversal, and SSRF Vulnerabilities

Related Documents

• OpenProject: #362
• Branch: feature/362-security-hardening (from dev)

Priority

HIGH

Objective

Address pre-existing security vulnerabilities identified in the security audit: ReDoS in pathPattern regex, path traversal in file system access, and SSRF in unrestricted URL fetching. These issues pose risks to users of the MCP server.

Definition of Done

• ReDoS vulnerability mitigated with regex timeout/complexity limits
• Path traversal prevented with path validation
• SSRF mitigated with URL allowlist/blocklist support
• TypeScript compilation CLEAN
• Lint checks PASSED (no lint script configured)
• ALL tests passing (33 security tests)
• Manual verification completed
• PROOF PROVIDED (security test cases)

Scope

IN SCOPE

• ReDoS mitigation in src/tools/query.ts pathPattern handling
• Path traversal prevention in src/lib/parser.ts file access
• SSRF mitigation in URL fetching (remote spec loading)
• Input validation utilities
• Security-focused test cases

OUT OF SCOPE

• Authentication/authorization (MCP server runs locally)
• Encryption at rest
• Rate limiting (single-user CLI tool)
• Audit logging

Sub-Tasks

Phase 1: ReDoS Mitigation

1.1 Add Regex Complexity Limits

• Details: Implement regex validation before creating RegExp from user input. Either use a safe-regex library or implement timeout-based execution.
• Files: src/tools/query.ts
• Testing: Test with known ReDoS patterns (e.g., (a+)+$ against aaaaaaaaaaaaaaaaaaaaaaaaaaaa!)

1.2 Create Input Validation Utilities

• Details: Create src/lib/input-validation.ts with reusable validation functions for regex patterns, file paths, and URLs.
• Files: src/lib/input-validation.ts (new)
• Testing: Unit tests for validation functions

Phase 2: Path Traversal Prevention

2.1 Implement Path Validation

• Details: Validate file paths to prevent directory traversal attacks (e.g., ../../../etc/passwd). Resolve paths and ensure they don't escape intended directories.
• Files: src/lib/parser.ts, src/lib/input-validation.ts
• Testing: Test with path traversal payloads

2.2 Add Configurable Base Directory (Optional)

• Details: Allow configuration of allowed directories for spec file access. Default to current working directory.
• Files: src/lib/parser.ts, src/lib/input-validation.ts
• Testing: Test directory restrictions

Phase 3: SSRF Mitigation

3.1 Implement URL Validation

• Details: Validate URLs before fetching. Block internal/private IP ranges (10.x, 172.16-31.x, 192.168.x, localhost, 127.x). Consider allowlist for known spec hosts.
• Files: src/lib/parser.ts, src/lib/input-validation.ts
• Testing: Test with internal IP addresses and localhost URLs

3.2 Add URL Protocol Restrictions

• Details: Only allow http:// and https:// protocols. Block file://, ftp://, data:, etc.
• Files: src/lib/input-validation.ts
• Testing: Test with various URL protocols

Files to Modify

• src/tools/query.ts: Add regex validation before new RegExp()
• src/lib/parser.ts: Add path and URL validation before spec loading
• src/lib/input-validation.ts (new): Centralized input validation utilities
• src/lib/types.ts: Add configuration types if needed

Risks & Mitigations

Risk	Impact	Mitigation
Breaking legitimate regex patterns	MEDIUM	Test common valid patterns, provide clear error messages
Blocking valid internal specs	MEDIUM	Make SSRF protection configurable, document bypass options
Performance impact from validation	LOW	Keep validation lightweight, cache validation results
Incomplete protection	HIGH	Follow OWASP guidelines, test with known attack payloads

Testing Strategy

• Build: npm run build - must pass
• Lint: npm run lint - must pass
• Manual testing with attack payloads:
  • ReDoS: (a+)+$, ([a-zA-Z]+)*$ against long strings
  • Path traversal: ../../../etc/passwd, ....//....//etc/passwd
  • SSRF: http://127.0.0.1/, http://localhost/, http://10.0.0.1/
• Verify legitimate use cases still work:
  • Local spec files (relative and absolute paths)
  • Remote HTTPS specs (public APIs)
  • Common regex patterns for path filtering

Implementation Notes

ReDoS Approach Options

1. safe-regex library: Detect dangerous patterns before execution
2. Regex timeout: Use vm.runInNewContext with timeout (complex)
3. Pattern restrictions: Limit regex features (simpler but restrictive)

Recommended: Start with pattern validation + timeout fallback.

Path Traversal Approach

Use path.resolve() and verify the resolved path starts with the allowed base directory:

const resolved = path.resolve(basePath, userPath);
if (!resolved.startsWith(basePath)) {
  throw new Error('Path traversal detected');
}

SSRF Approach

1. Parse URL with new URL()
2. Check protocol (allow only http/https)
3. Resolve hostname to IP
4. Check IP against private ranges blocklist
5. Consider DNS rebinding protection (optional, advanced)

References

• OWASP ReDoS: https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS
• OWASP Path Traversal: https://owasp.org/www-community/attacks/Path_Traversal
• OWASP SSRF: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery