[jira] [Commented] (CAMEL-24451) camel-xslt - all headers are bound as stylesheet parameters and XsltUriResolver bypasses the JAXP external-access limits

["Andrea Cosentino (Jira)" <ji...@apache.org>]

    [ 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)