Security: Sensitive Header Names Not Validated for Env Var Safety

[tomaioo]

Summary

Security: Sensitive Header Names Not Validated for Env Var Safety

Problem

Severity: Medium | File: cmd/thv-operator/pkg/controllerutil/telemetry.go:L52

In GenerateOpenTelemetryEnvVarsFromRef, the normalizeHeaderEnvVarName function converts header names to environment variable names by only replacing dashes with underscores and uppercasing. However, it does not validate that the resulting string is a valid environment variable name (e.g., it could start with a digit, contain invalid characters, or be empty). This could lead to invalid environment variable configurations in pods. More critically, if a malicious user can control header names through the CRD, they could potentially craft header names that cause unexpected behavior or conflicts with system environment variables.

Solution

Add validation to normalizeHeaderEnvVarName to ensure the resulting environment variable name is valid: must start with a letter or underscore, contain only alphanumeric characters and underscores, and not exceed standard env var length limits. Also consider adding a prefix to avoid collisions with system environment variables.

Changes

• cmd/thv-operator/pkg/controllerutil/telemetry.go (modified)

[ChrisJBurns]

@tomaioo Would you be able to add some unit tests here to verify the new code?

[aponcedeleonch]

Thanks for flagging this. Before we can take a change like this, we ask contributors to open an issue describing the problem and get it assigned to them first, per our contributor guidelines. There's no linked issue here, so that's where we'd like to start: could you open one describing the env-var-name validation gap in normalizeHeaderEnvVarName so we can triage it and confirm the approach before code review?

Going to close this for now on that basis, not on the technical merits. Once the issue's up and assigned, feel free to resubmit and we'll take a proper look.