[
https://issues.apache.org/jira/browse/CAMEL-23321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18073274#comment-18073274
]
Claus Ibsen commented on CAMEL-23321:
-------------------------------------
Some JMS brokers has allow/deny list for classes on the broker side, so its
safe for those.
[https://docs.redhat.com/en/documentation/red_hat_amq/6.3/html/security_guide/securebroker-objectmessage]
[https://activemq.apache.org/components/classic/documentation/objectmessage]
> camel-jms, camel-sjms, camel-amqp - Add deserialization filtering for
> ObjectMessage handling
> --------------------------------------------------------------------------------------------
>
> Key: CAMEL-23321
> URL: https://issues.apache.org/jira/browse/CAMEL-23321
> Project: Camel
> Issue Type: Improvement
> Components: camel-amqp, camel-jms, camel-sjms
> Reporter: Andrea Cosentino
> Priority: Major
>
> Align the JMS component family with the deserialization-filtering pattern
> already applied in camel-netty (CAMEL-23297) and camel-mina (CAMEL-23319).
> h3. Background
> JmsBinding.extractBodyFromJms() converts incoming JMS messages into the
> Exchange body. For ObjectMessage inputs it calls ObjectMessage.getObject(),
> which delegates deserialization to the JMS provider layer. Camel itself does
> not attach an ObjectInputFilter, does not expose a class allow/deny list, and
> does not consult jdk.serialFilter at the framework layer.
> The same extraction shape is present in:
> *
> components/camel-jms/src/main/java/org/apache/camel/component/jms/JmsBinding.java
> (lines ~140-150)
> *
> components/camel-sjms/src/main/java/org/apache/camel/component/sjms/jms/JmsBinding.java
> (lines ~101-111)
> *
> components/camel-amqp/src/main/java/org/apache/camel/component/amqp/AMQPJmsBinding.java
> (inherits extractBodyFromJms() from JmsBinding without override)
> The mapJmsMessage configuration option defaults to true
> (JmsConfiguration.java, line 260), so the ObjectMessage extraction branch is
> active for every JMS consumer endpoint unless explicitly disabled.
> h3. Proposed change
> * Add a configurable option on JmsConfiguration (e.g. a class allowlist
> pattern or a flag to disable ObjectMessage extraction) so users can constrain
> what the binding will accept. Shape should mirror the camel-mina /
> camel-netty work where reasonable, with the caveat that the JmsBinding does
> not own the ObjectInputStream and therefore cannot simply call
> setObjectInputFilter on it.
> * Continue to support the existing DefaultExchangeHolder path used by
> transferExchange without requiring extra user configuration.
> * Document the option, plus guidance on configuring the underlying JMS
> provider's own class filter (Artemis deserializationWhiteList /
> deserializationBlackList, ActiveMQ setTrustedPackages, Qpid JMS
> deserializationPolicy allow list) and JVM-wide -Djdk.serialFilter.
> * Update the existing caution note for transferExchange / transferException
> (see CAMEL-13829) to cross-reference the new option.
> h3. Out of scope
> * Changing the mapJmsMessage default.
> * Changing the behaviour of TextMessage / BytesMessage / MapMessage /
> StreamMessage paths.
> h3. Related
> * CAMEL-23297 - Add deserialization filtering to camel-netty converters and
> codecs
> * CAMEL-23319 - Add deserialization filtering to camel-mina converter
> * CAMEL-13829 - Add caution to transferExchange/transferException option on
> JMS components
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
