GitHub user ppkarwasz created a discussion: Threat model: how should Thread Context (MDC) keys be classified (trusted structural or untrusted content)?
## Background I am revising the common threat model (`_threat-model-common.adoc`) to define data sources by *who controls them*: configuration (operator-controlled, trusted), structural identifiers / control (developer-controlled, trusted), and content (user-controlled, untrusted). Most inputs fit one category cleanly. Thread Context (the Log4j `ThreadContext` MDC/NDC, and the equivalent context maps in Log4net and Log4cxx) does not. We have discussed this in private and now want to settle it in a public venue. ## The question Thread Context **values** are clearly user-controlled content, hence untrusted. Thread Context **keys** are ambiguous: - They behave like **structural identifiers**: developer-chosen, usually constants such as a `requestId` key. That would make them trusted, and key-based injection a case of application misuse. - But a common (and discouraged) practice is to copy untrusted data wholesale into the context, for example dumping all HTTP headers into the MDC. That would make keys effectively user-controlled, hence untrusted. How we classify keys decides whether key-based injection or validation-DoS reports are in scope, and what the correct remediation is: neutralize untrusted content, validate and reject trusted input, or document the case as application misuse. ## Points to decide 1. Are MDC keys structural identifiers (developer-controlled, trusted) or content (user-controlled, untrusted)? 2. Should keys and values be classified differently? 3. If keys are trusted: should "do not populate Thread Context keys from untrusted input, e.g. raw HTTP header names" be a documented developer responsibility, with violations treated as out of scope? 4. Does the answer hold equally for Log4j, Log4net, and Log4cxx, given this is the **common** threat model? > [!NOTE] > Everyone is welcome to contribute. As usual, opinions expressed by Logging > Services PMC members are binding for the project's security policy. In the meantime, the threat-model refactor will document Thread Context values as untrusted content and mark keys as a known open gap pointing to this discussion. GitHub link: https://github.com/apache/logging-log4j2/discussions/4132 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
