Andrea Cosentino created CAMEL-24210:
----------------------------------------
Summary: camel-openai: secrets passed via additionalHeader.* are
not redacted from sanitized URIs
Key: CAMEL-24210
URL: https://issues.apache.org/jira/browse/CAMEL-24210
Project: Camel
Issue Type: Improvement
Components: camel-openai
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
Follow-up hardening item from CAMEL-23968, which added the
{{additionalHeader.*}} multi-value option to camel-openai.
h3. Problem
The option is declared with {{security = "secret"}} in {{OpenAIConfiguration}},
and its own description recommends:
{noformat}
additionalHeader.api-key=secret
{noformat}
However, that annotation drives catalog metadata and tooling only. Runtime
redaction in {{URISupport.sanitizeUri}} is keyword-driven: a query parameter is
masked only when its *name contains* one of the keywords in {{SensitiveUtils}}
as a case-insensitive substring.
Checking realistic header names against the current keyword list:
|| URI parameter || Masked || Reason ||
| {{apiKey=...}} | yes | matches {{apikey}} |
| {{additionalHeader.X-Api-Token=...}} | yes | matches {{token}} |
| {{additionalHeader.api-key=...}} | *no* | the hyphen breaks the {{apikey}}
substring; bare {{key}} is not a keyword |
| {{additionalHeader.Authorization=...}} | *no* | only {{authorizationtoken}}
is a keyword |
So a credential passed through {{additionalHeader.*}} with a hyphenated or
{{Authorization}}-style header name is written in clear text wherever a
sanitized endpoint URI is emitted (logs, JMX attributes, exception messages,
developer console).
{{api-key}} is the Azure OpenAI authentication header, which is precisely the
case a user would combine with a custom {{baseUrl}} -- so the form the option's
own documentation recommends is the one that is *not* redacted.
h3. Scope
This is hardening / defence in depth, not a framework vulnerability. The actor
placing the secret into the endpoint URI is the route author, who is fully
trusted under the project threat model, and no untrusted input crosses a trust
boundary. It is filed as a normal improvement rather than through the private
security process. The concern is that Camel already redacts {{apiKey}}, so
users reasonably expect credentials in endpoint URIs to be masked, and here
that expectation silently does not hold.
h3. Suggested fix
Any of, in rough order of preference:
# Register the missing keywords via {{URISupport.addSanitizeKeywords}} so
hyphenated and {{Authorization}}-style names are covered.
# Add {{api-key}} / {{authorization}} to the {{SensitiveUtils}} keyword list
(broader blast radius across all components -- needs care, since substring
matching means bare {{key}} would over-match).
# At minimum, change the option description so it stops steering users toward
the unredacted shape.
h3. Related follow-ups from the same review (not covered by this issue)
* Headers supplied via {{additionalHeader.*}} are *appended* rather than
replacing existing ones, so {{additionalHeader.Authorization=...}} results in
two {{Authorization}} values on the request (the SDK-generated {{Bearer
<apiKey>}} first). Undocumented and untested.
* The three options added in CAMEL-23968 received no prose documentation,
although {{openai-component.adoc}} has a dedicated section for the directly
comparable {{additionalResponseHeader}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
