[
https://issues.apache.org/jira/browse/CAMEL-25704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino updated CAMEL-25704:
-------------------------------------
Description:
The undertow producer writes the path, query and header values of the outgoing
HTTP request to the socket one character at a time, without validating them. A
control character such as a carriage return or line feed was therefore written
into the request line or a header line, producing a malformed request, and a
character above 0xFF was narrowed to a single, different byte (for example
U+010A was written as a line feed).
The producer decodes a percent-encoded CamelHttpPath or CamelHttpQuery before
building the request target (URISupport.pathAndQueryOf uses the decoded
URI.getPath() and URI.getQuery()), so a percent-encoded control character in
those headers became a real control character at that point.
Expected: the producer refuses to send a request path, query or header value
that contains a control character or a character above 0xFF, failing the
exchange instead. A space and a tab, which do not change the request framing,
are still allowed.
Note: the decoding of CamelHttpPath/CamelHttpQuery is kept for compatibility.
The rest producer double-encodes its query parameters and relies on the
undertow producer decoding once (CAMEL-15410), so the fix keeps the decoding
and only refuses characters that cannot be written as they are.
was:
The undertow producer builds the path and query of the HTTP request from the
decoded parts of the target URI (URISupport.pathAndQueryOf uses URI.getPath()
and URI.getQuery()). Characters that are percent-encoded in the endpoint URI,
in the CamelHttpPath and CamelHttpQuery headers, or by the rest producer for
query parameters are therefore sent decoded:
- %26 and %3D in a query value become & and =, so one parameter is received as
several
- %2F in a path segment becomes /, and an encoded dot segment becomes a real one
- %20 becomes a space in the request line, which the server rejects
- a non-ASCII character is written as a single byte instead of its UTF-8
encoding
- header values with characters outside ISO-8859-1 are written the same way
The http, netty-http and vertx-http producers send the encoded form. Before
2.19.0 (CAMEL-10929) the undertow producer did too.
Expected: the producer sends the path and query as encoded, with non-ASCII
characters percent-encoded as UTF-8, and rejects a request target or header
value that it cannot send as is. The vertx-websocket client builds its
handshake URI with the same helper (URISupport.pathAndQueryOf) and should be
aligned.
Summary: camel-undertow - the producer refuses a request target or
header value it cannot write as it is (was: camel-undertow - the producer
sends the request path and query decoded instead of as they are encoded)
> camel-undertow - the producer refuses a request target or header value it
> cannot write as it is
> -----------------------------------------------------------------------------------------------
>
> Key: CAMEL-25704
> URL: https://issues.apache.org/jira/browse/CAMEL-25704
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-undertow
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.18.6, 4.22.2, 4.24.0
>
>
> The undertow producer writes the path, query and header values of the
> outgoing HTTP request to the socket one character at a time, without
> validating them. A control character such as a carriage return or line feed
> was therefore written into the request line or a header line, producing a
> malformed request, and a character above 0xFF was narrowed to a single,
> different byte (for example U+010A was written as a line feed).
> The producer decodes a percent-encoded CamelHttpPath or CamelHttpQuery before
> building the request target (URISupport.pathAndQueryOf uses the decoded
> URI.getPath() and URI.getQuery()), so a percent-encoded control character in
> those headers became a real control character at that point.
> Expected: the producer refuses to send a request path, query or header value
> that contains a control character or a character above 0xFF, failing the
> exchange instead. A space and a tab, which do not change the request framing,
> are still allowed.
> Note: the decoding of CamelHttpPath/CamelHttpQuery is kept for compatibility.
> The rest producer double-encodes its query parameters and relies on the
> undertow producer decoding once (CAMEL-15410), so the fix keeps the decoding
> and only refuses characters that cannot be written as they are.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
