[
https://issues.apache.org/jira/browse/CAMEL-25483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shashank updated CAMEL-25483:
-----------------------------
Description:
camel-rest-postman (CAMEL-24367) is on main only; it affects only unreleased
4.23.0-SNAPSHOT, so this is pre-release hardening.
{{PostmanVariableResolver.lookup()}} resolves a \{\{name\}\} placeholder that
neither the collection nor the {{variables}} option defines through
camelContext.resolvePropertyPlaceholders("\{\{" + name + "\}\}").
{{isSafeToResolveAsProperty()}} only refuses names containing {{:}} (so
\{\{env:X\}\}, \{\{sys:X\}\} and vault functions are blocked). The component
page gives the reason: a cloud-hosted collection is editable by anyone with
access to the Postman workspace, and its content must not pull an environment
variable into an outgoing request. A plain name bypasses this. The properties
component's default {{environmentVariableMode}} and {{systemPropertiesMode}}
are OVERRIDE, so \{\{DB_PASSWORD\}\} resolves the OS environment variable,
\{\{some.prop\}\} a JVM system property, and any name an application property
(e.g. {{camel.component.x.password}}). {{PostmanRequestMapper}} puts the
resolved values into the outgoing headers, query, URL and body. A collection
fetched over HTTP has the same exposure through whoever serves it.
Second path: the collection's {{Accept}} and {{Content-Type}} values are not
substituted at all. They go verbatim into the delegate {{rest:}} endpoint URI
({{consumes}}/{{produces}}), and {{getEndpoint}} resolves property placeholders
there, functions included, for any collection source.
h3. Reproduction
Collection with a request header X-Leak: \{\{leakProbe\}\}, a Camel property
{{leakProbe=from-camel-properties}}, and a JVM system property used the same
way. Fetched from a stub Postman API
({{rest-postman:<uid>#getStatus?postmanApiUrl=...}}) or over HTTP, the target
API receives {{X-Leak: from-camel-properties}} and the system property's value.
A classpath collection with Accept: \{\{sys:some.prop\}\} sends the system
property as {{Accept}}. On main 7c0fca7a09cb.
h3. Proposed fix
* Resolve undefined placeholders from Camel properties only for a collection
read from the classpath or the file system ({{classpath:}}, {{file:}} or no
scheme), not for the Postman cloud, http(s) or any other resource scheme. New
option {{resolveVariablesFromProperties}} with the values {{auto}} (default:
the source-based rule above), {{enabled}} (the lookup for any source) and
{{disabled}} (no lookup, local collections included); an unknown value fails
producer creation. Keep the {{prefix:value}} refusal.
* Substitute {{Accept}}/{{Content-Type}} like the other header values, and fail
producer creation when the delegate URI or a query parameter (name or value)
still contains a \{\{placeholder\}\}, instead of letting {{getEndpoint}}
resolve it from properties.
* Update the Variables section of the component page. No upgrade-guide entry
(unreleased component).
Duplicate check (2026-10-08): no camel-rest-postman JIRA component. Text search
"postman" in CAMEL finds CAMEL-24367 (the component) and CAMEL-24978, neither
about this. GitHub pull requests "postman": #25390 (the component), #27469
(CAMEL-25306, path decoding), none open on this.
_Filed with Claude Code on behalf of allthingssecurity._
was:
camel-rest-postman (CAMEL-24367) is on main only; it affects only unreleased
4.23.0-SNAPSHOT, so this is pre-release hardening.
{{PostmanVariableResolver.lookup()}} resolves a \{\{name\}\} placeholder that
neither the collection nor the {{variables}} option defines through
camelContext.resolvePropertyPlaceholders("\{\{" + name + "\}\}").
{{isSafeToResolveAsProperty()}} only refuses names containing {{:}} (so
\{\{env:X\}\}, \{\{sys:X\}\} and vault functions are blocked). The component
page gives the reason: a cloud-hosted collection is editable by anyone with
access to the Postman workspace, and its content must not pull an environment
variable into an outgoing request. A plain name bypasses this. The properties
component's default {{environmentVariableMode}} and {{systemPropertiesMode}}
are OVERRIDE, so \{\{DB_PASSWORD\}\} resolves the OS environment variable,
\{\{some.prop\}\} a JVM system property, and any name an application property
(e.g. {{camel.component.x.password}}). {{PostmanRequestMapper}} puts the
resolved values into the outgoing headers, query, URL and body. A collection
fetched over HTTP has the same exposure through whoever serves it.
Second path: the collection's {{Accept}} and {{Content-Type}} values are not
substituted at all. They go verbatim into the delegate {{rest:}} endpoint URI
({{consumes}}/{{produces}}), and {{getEndpoint}} resolves property placeholders
there, functions included, for any collection source.
h3. Reproduction
Collection with a request header X-Leak: \{\{leakProbe\}\}, a Camel property
{{leakProbe=from-camel-properties}}, and a JVM system property used the same
way. Fetched from a stub Postman API
({{rest-postman:<uid>#getStatus?postmanApiUrl=...}}) or over HTTP, the target
API receives {{X-Leak: from-camel-properties}} and the system property's value.
A classpath collection with Accept: \{\{sys:some.prop\}\} sends the system
property as {{Accept}}. On main 7c0fca7a09cb.
h3. Proposed fix
* Resolve undefined placeholders from Camel properties only for a collection
read from the classpath or the file system ({{classpath:}}, {{file:}} or no
scheme), not for the Postman cloud, http(s) or any other resource scheme. New
option {{resolveVariablesFromProperties}} (Boolean): unset means the
source-based default, true enables the lookup for any source, false disables it
for local collections too. Keep the {{prefix:value}} refusal.
* Substitute {{Accept}}/{{Content-Type}} like the other header values, and fail
producer creation when the delegate URI still contains a \{\{placeholder\}\},
instead of letting {{getEndpoint}} resolve it from properties.
* Update the Variables section of the component page. No upgrade-guide entry
(unreleased component).
Duplicate check (2026-10-08): no camel-rest-postman JIRA component. Text search
"postman" in CAMEL finds CAMEL-24367 (the component) and CAMEL-24978, neither
about this. GitHub pull requests "postman": #25390 (the component), #27469
(CAMEL-25306, path decoding), none open on this.
_Filed with Claude Code on behalf of allthingssecurity._
> camel-rest-postman - a remote collection's placeholders resolve Camel
> properties, JVM system properties and environment variables
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25483
> URL: https://issues.apache.org/jira/browse/CAMEL-25483
> Project: Camel
> Issue Type: Bug
> Components: camel-rest-openapi
> Reporter: shashank
> Assignee: shashank
> Priority: Major
>
> camel-rest-postman (CAMEL-24367) is on main only; it affects only unreleased
> 4.23.0-SNAPSHOT, so this is pre-release hardening.
> {{PostmanVariableResolver.lookup()}} resolves a \{\{name\}\} placeholder that
> neither the collection nor the {{variables}} option defines through
> camelContext.resolvePropertyPlaceholders("\{\{" + name + "\}\}").
> {{isSafeToResolveAsProperty()}} only refuses names containing {{:}} (so
> \{\{env:X\}\}, \{\{sys:X\}\} and vault functions are blocked). The component
> page gives the reason: a cloud-hosted collection is editable by anyone with
> access to the Postman workspace, and its content must not pull an environment
> variable into an outgoing request. A plain name bypasses this. The properties
> component's default {{environmentVariableMode}} and {{systemPropertiesMode}}
> are OVERRIDE, so \{\{DB_PASSWORD\}\} resolves the OS environment variable,
> \{\{some.prop\}\} a JVM system property, and any name an application property
> (e.g. {{camel.component.x.password}}). {{PostmanRequestMapper}} puts the
> resolved values into the outgoing headers, query, URL and body. A collection
> fetched over HTTP has the same exposure through whoever serves it.
> Second path: the collection's {{Accept}} and {{Content-Type}} values are not
> substituted at all. They go verbatim into the delegate {{rest:}} endpoint URI
> ({{consumes}}/{{produces}}), and {{getEndpoint}} resolves property
> placeholders there, functions included, for any collection source.
> h3. Reproduction
> Collection with a request header X-Leak: \{\{leakProbe\}\}, a Camel property
> {{leakProbe=from-camel-properties}}, and a JVM system property used the same
> way. Fetched from a stub Postman API
> ({{rest-postman:<uid>#getStatus?postmanApiUrl=...}}) or over HTTP, the target
> API receives {{X-Leak: from-camel-properties}} and the system property's
> value. A classpath collection with Accept: \{\{sys:some.prop\}\} sends the
> system property as {{Accept}}. On main 7c0fca7a09cb.
> h3. Proposed fix
> * Resolve undefined placeholders from Camel properties only for a collection
> read from the classpath or the file system ({{classpath:}}, {{file:}} or no
> scheme), not for the Postman cloud, http(s) or any other resource scheme. New
> option {{resolveVariablesFromProperties}} with the values {{auto}} (default:
> the source-based rule above), {{enabled}} (the lookup for any source) and
> {{disabled}} (no lookup, local collections included); an unknown value fails
> producer creation. Keep the {{prefix:value}} refusal.
> * Substitute {{Accept}}/{{Content-Type}} like the other header values, and
> fail producer creation when the delegate URI or a query parameter (name or
> value) still contains a \{\{placeholder\}\}, instead of letting
> {{getEndpoint}} resolve it from properties.
> * Update the Variables section of the component page. No upgrade-guide entry
> (unreleased component).
> Duplicate check (2026-10-08): no camel-rest-postman JIRA component. Text
> search "postman" in CAMEL finds CAMEL-24367 (the component) and CAMEL-24978,
> neither about this. GitHub pull requests "postman": #25390 (the component),
> #27469 (CAMEL-25306, path decoding), none open on this.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
