BudgetScan

Unvalidated host input allows unbounded certificate material and nonconforming SANs

low swesweep-fasthttp · tls.go · GenerateTestCertificate · run #4

Description

The host parameter is placed directly into cert.DNSNames without length or DNS-name validation. An attacker-influenced very long host can cause DER/PEM allocation and processing proportional to the input, while invalid or wildcard hostnames can produce nonconforming or overly broad subject alternative names if the generated certificate is used outside tests.

Triage

Not triaged.

Raw scan report for this file

I analyzed `tls.go` under the library threat model: the exported `GenerateTestCertificate(host)` is the trust boundary, and `host` is the main externally influenced input. The function has no fixed-size buffers, unsafe memory operations, goroutines, external commands, or slice indexing, so I do not see a Go memory-safety zero-day here. The main risks are input-validation/resource-consumption issues and an error-handling footgun.

Key observations:

- `host` is copied directly into `cert.DNSNames` without length, DNS syntax, or wildcard validation. A very long attacker-influenced host can cause allocation and encoding work proportional to the input. A malformed or wildcard hostname can produce a nonconforming or overly broad SAN if the generated certificate is used outside a controlled test context.
- Every call generates a 2048-bit RSA key. If this exported helper is reachable from a request path or otherwise invoked repeatedly with untrusted input, it becomes a CPU/memory DoS surface.
- If `x509.CreateCertificate` fails, the code still PEM-encodes `certBytes`, which may be nil/invalid, and returns a non-nil `CERTIFICATE` PEM block alongside the error. A caller that misuses the return values or ignores the error may handle an invalid certificate object.
- The certificate is generated as a CA (`IsCA: true`) with a 365-day validity period. This is expected for a test helper, but it would be a lifecycle/trust issue if accidentally deployed to production. I did not list that as a primary finding because it is more a usage/design concern than a directly triggerable code vulnerability.

```json
[
  {
    "severity": "low",
    "title": "Unvalidated host input allows unbounded certificate material and nonconforming SANs",
    "function": "GenerateTestCertificate",
    "description": "The host parameter is placed directly into cert.DNSNames without length or DNS-name validation. An attacker-influenced very long host can cause DER/PEM allocation and processing proportional to the input, while invalid or wildcard hostnames can produce nonconforming or overly broad subject alternative names if the generated certificate is used outside tests."
  },
  {
    "severity": "low",
    "title": "Expensive RSA-2048 key generation on every call is a DoS surface",
    "function": "GenerateTestCertificate",
    "description": "Each invocation generates a 2048-bit RSA private key and a certificate. If this public helper is called with attacker-influenced input in a request path or without rate limiting, an external attacker can trigger repeated CPU- and memory-intensive key generation."
  },
  {
    "severity": "low",
    "title": "Invalid certificate PEM is returned when x509.CreateCertificate fails",
    "function": "GenerateTestCertificate",
    "description": "certBytes is encoded into a PEM block even if x509.CreateCertificate returns an error. The function then returns a non-nil, syntactically present but invalid CERTIFICATE PEM alongside the error. Callers that misuse the return values or ignore the error may use an invalid certificate; on failure the certificate return value should be nil."
  }
]
```