[
https://issues.apache.org/jira/browse/CAMEL-24451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18107296#comment-18107296
]
Andrea Cosentino commented on CAMEL-24451:
------------------------------------------
Not implementing the two changes in the description as written, because both
turned out to conflict with documented behaviour. Handing the scope decision
back.
*1. Gating the header-to-parameter binding cannot be a default.*
The component documents this as its primary mechanism. From
{{xslt-component.adoc}}, under "Getting Usable Parameters into the XSLT":
{quote}
By default, all headers and variables are added as parameters which are then
available in the XSLT. To make the parameters usable, you will need to declare
them.
{quote}
The section then teaches setting a header and declaring the matching
{{xsl:param}}. Defaulting the binding off would break the documented way of
passing parameters to a stylesheet, so any restriction has to be opt-in - which
means it protects nobody who has not already thought about it.
*2. The URIResolver is not bypassing anything Camel configured.*
{{configureTransformer()}} does always install {{XsltUriResolver}}, and JAXP
consults {{ACCESS_EXTERNAL_DTD}} / {{ACCESS_EXTERNAL_STYLESHEET}} only when no
{{URIResolver}} returns a {{Source}} - so far as described. But a repo-wide
search finds camel-xslt setting neither property anywhere, so there is no
Camel-configured restriction being defeated.
*What is left, and it is real.* An operator who hardens the factory themselves,
through the {{TransformerFactoryConfigurationStrategy}} hook the component
provides, gets no protection: the always-installed resolver still resolves
{{classpath:}}, {{file:}}, {{http:}}, {{ref:}} and {{bean:}} regardless. That
is a configured control silently doing nothing - the same shape as CAMEL-24427,
which was ruled a bug rather than a vulnerability.
*Recommendation.* Treat this as two smaller pieces, both for a maintainer to
weigh:
* Make {{XsltUriResolver}} honour {{ACCESS_EXTERNAL_DTD}} /
{{ACCESS_EXTERNAL_STYLESHEET}} when the operator has set them on the factory,
so the hook does what it appears to.
* Document, in the "Getting Usable Parameters into the XSLT" section, that the
binding includes headers arriving from outside the route, so a stylesheet using
a parameter inside {{document()}} is reachable from the wire - with
{{removeHeaders}} named as the mitigation.
I have made no code change on this issue. The CVE recommendation for the
corresponding scan finding has been withdrawn on this basis.
_Claude Code on behalf of oscerd_
> camel-xslt - all headers are bound as stylesheet parameters and
> XsltUriResolver bypasses the JAXP external-access limits
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24451
> URL: https://issues.apache.org/jira/browse/CAMEL-24451
> Project: Camel
> Issue Type: Bug
> Components: camel-xslt
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.23.0
>
>
> Two behaviours in {{XsltBuilder.configureTransformer()}} combine:
> 1. Every exchange property, message header and variable is bound as an XSLT
> parameter, with no opt-in. Message headers therefore silently shadow
> {{xsl:param}} defaults in the stylesheet.
> 2. {{XsltUriResolver}} is always installed. JAXP consults
> {{ACCESS_EXTERNAL_DTD}} / {{ACCESS_EXTERNAL_STYLESHEET}} only when no
> {{URIResolver}} returns a {{Source}}, so the resolver re-enables resolution
> of {{classpath:}}, {{file:}}, {{http:}}, {{ref:}} and {{bean:}} URIs
> regardless of those settings.
> Where a stylesheet uses a parameter inside {{document()}} - a normal pattern
> - a message header decides what the transform reads. The stylesheet author
> never asked for header binding, and the operator's external-access
> configuration does not apply.
> Proposal: gate the automatic parameter binding behind an option (an explicit
> parameter list, or an {{allowParametersFromHeaders}} flag defaulting to
> false), and make {{XsltUriResolver}} honour the configured
> {{ACCESS_EXTERNAL_*}} values rather than sitting in front of them. Both are
> behaviour changes and need upgrade-guide entries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
