41 lines
3.7 KiB
Markdown
41 lines
3.7 KiB
Markdown
# Threat model
|
|
|
|
## Assets
|
|
|
|
CertScope protects the host running the inspector from becoming a generic network pivot while preserving enough evidence to troubleshoot public DNS/TLS/HTTP posture. It also protects report consumers from misleading scores and unescaped exported content.
|
|
|
|
## Primary threats
|
|
|
|
1. **SSRF into private infrastructure.** A user-controlled hostname or redirect could resolve to loopback, link-local, RFC1918, CGNAT, ULA, multicast or other non-public space.
|
|
2. **DNS rebinding / TOCTOU.** A safe first lookup could be followed by a different answer before a socket is opened, or a redirect target could resolve privately.
|
|
3. **Port and scheme escalation.** A redirect could attempt `file:`, credentials, protocol confusion or an arbitrary port.
|
|
4. **Unbounded work.** Redirect loops, many addresses or stalled DNS/sockets could consume server resources or create concurrent connection pressure.
|
|
5. **Misleading partial evidence or stale provenance.** A failed record family or hop could be mistaken for an absent control, or a failed new request could make a prior demo report appear live.
|
|
6. **Report/content injection.** Hostnames, headers and diagnostic text could break the UI or Markdown exports if rendered without escaping.
|
|
|
|
## Controls
|
|
|
|
- hostname-only input validation, lower-case normalization and safe IDN-to-ASCII conversion;
|
|
- public-unicast validation for every resolved A/AAAA answer before any candidate is attempted;
|
|
- direct IP connection after validation, retaining the normalized hostname only for Host/SNI, so the connect path does not ask the OS to resolve the hostname again;
|
|
- bounded multi-address fallback with a hard total deadline and recorded candidate failures;
|
|
- re-resolution and target validation for every redirect hop;
|
|
- HTTP(S)-only, default ports only, maximum three redirect hops, normalized visited-URL loop detection and explicit HTTPS downgrade blocking;
|
|
- four-second DNS, eight-second TLS and 15-second HTTP aggregate budgets, plus per-operation timers and socket/response teardown;
|
|
- explicit collector `_meta.status` and error evidence, with score deductions applied only to observed evidence;
|
|
- client-side structural validation before a successful API payload can replace a valid report, plus retained and explicitly labelled prior evidence on request failure;
|
|
- typed header posture shared by diagnostics and UI, including CSP first-directive-wins behavior, browser-style Referrer-Policy fallback lists and `Unavailable` rather than inferred negative controls;
|
|
- deterministic, non-AI diagnostic rules with stable IDs and an equal-weighted category score;
|
|
- React escaping for UI values and length-safe Markdown escaping/fenced JSON exports;
|
|
- process-local four-slot admission and 30-per-minute fair-use limiting. Forwarded headers are ignored unless an operator explicitly trusts the reverse proxy;
|
|
- no persistence, credential handling, arbitrary shell execution or background jobs in the MVP;
|
|
- container non-root, read-only root filesystem, dropped capabilities, no-new-privileges and bounded temporary storage.
|
|
|
|
## Residual risk and assumptions
|
|
|
|
The deployment is intentionally unauthenticated and should be kept behind the intended network boundary or an operator-controlled access layer. The process-local limiter is not shared across replicas. DNS and public routing can change after an individual validated connection; CertScope makes no claim about future state. It also does not inspect response bodies or prove application-level authorization.
|
|
|
|
## Out of scope
|
|
|
|
CertScope does not perform port scanning, subdomain enumeration, vulnerability exploitation, authenticated crawling, private-network inspection, history persistence, monitoring daemon work or multi-host inventory.
|