Eyrie-Templates/THREAT_MODEL.md
2026-01-06 17:29:10 -06:00

101 lines
4.4 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Eyrie Templates — Threat Model (Draft)
Purpose: identify assets, threats, and controls relevant to a serverside PHP templating engine and define baseline mitigations.
## 1. Assets
- Template sources (files and compiled cache outputs)
- Rendered HTML output delivered to clients
- Template context data (user data, secrets if accidentally passed)
- Component definitions/renderers and their configuration
- Helper/filter registry and configuration
- Loader configuration (roots, namespaces)
- Cache directory and compiled artifacts
- Error logs and diagnostics
## 2. Actors
- Application developers (trusted, may misconfigure)
- End users (untrusted input surfaces)
- Attackers supplying malicious input
- System administrators (manage deployment and FS perms)
## 3. Trust boundaries
- Between untrusted user input and template rendering
- Between template engine and filesystem (loaders, cache)
- Between engine and helper/filter callables (application code)
- Between dev and prod environments (verbosity, paths, timings)
## 4. Entry points and attack surfaces
- Template variables/expressions from requestderived data (XSS)
- Helper/filter parameters (command/code injection via helpers)
- Component props/attributes (injection vectors; type confusion)
- Template name resolution (path traversal, namespace bypass)
- Include/extends directives (recursive includes, deep inheritance)
- Component trees (deep recursion/nesting)
- Large templates or pathological inputs (parser/render DoS)
- Cache poisoning or disclosure (incorrect perms or keying)
- Error pages and stack traces (info leakage)
## 5. Threats and mitigations
- Reflected/stored XSS in output
- Default autoescaping with context modes (`html`, `attr`, `url`, `js`)
- `safe` must be explicit and narrowly scoped
- Security lint/checks to flag `safe` usage
- Path traversal via loader
- Normalize and resolve paths; reject `..` and absolute paths unless mapped
- Restrict to configured roots; support namespaces with fixed roots
- Code execution via helpers/filters
- Only whitelisted callables registered by application
- No evaluation of template strings as PHP; no reflection access
- Optionally sandbox helpers with contracts and safe value types
- Code execution or SSRF via component renderers
- Components implement a constrained interface; no filesystem/network access by default
- Validate and sanitize props before use; avoid passing raw props to sinks
- Enforce a strict registry: only explicitly added components are callable
- DoS via deep inheritance/recursion or huge loops
- Limits: include/extends depth; loop iteration caps; template/token size limits
- Watchdog timeouts for parse/render
- Component nesting/recursion depth caps and perrender time budgets
- Cache tampering/leakage
- Cache dir perms 0700; atomic writes; validate cache keys (include engine version and options)
- Avoid executing cache files; treat as data
- Information disclosure via errors
- Configurable verbosity; hide paths/snippets in production
- Structured error types without sensitive context values
- SSRF/RFI via helpers/filters
- No network/file IO in templates; helpers must not fetch remote resources by default
- Apply same restrictions to components
## 6. Assumptions
- Templates are developerauthored and trusted; usergenerated templates are out of scope.
- Application controls helper registrations; helpers conform to safe contracts.
- Deployment applies standard OS hardening (FS perms, no public cache dirs).
## 7. Security requirements (binding)
- Autoescaping enabled by default and cannot be globally disabled in production builds
- Loader prevents traversal; cannot escape configured roots
- Depth/size/time limits are configurable with safe defaults
- Distinct dev/prod modes, with safe prod defaults
- No eval of template source; no direct PHP execution from templates
- Components are pure render units; cannot mutate outer context; registered explicitly
## 8. Validation and testing
- XSS test corpus across HTML, attribute, JS, and URL contexts
- Fuzz tests for parser stability and timeouts
- Unit tests for loader normalization and traversal blocking
- Integration tests for cache directory perms and keying
- Component test suite for prop escaping, type validation, and recursion limits
## 9. Open items
- Define safe value wrapper interface
- Decide on strictvariables default (on/off)
- Finalize default limits (include depth, loop max, template size)