camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: [security] http4 endpoint headers "leaking"
Date Wed, 05 Aug 2015 12:56:42 GMT
The filter has both in and out now. You may use an older version of
Camel that may not do that.

If you use JBoss Fuse then contact the vendor.


On Wed, Aug 5, 2015 at 2:53 PM, James Green <james.mk.green@gmail.com> wrote:
> To follow-up, are we clear that the bug is when a remote HTTP server is
> called via to(http4:...) ? The remote side gets to see all the exchange
> headers, which is the leak.
>
> From your email I was reading you thought it was to do with the consumer
> being wrong but it's the producer we're seeing bad things on. I'm no expert
> but I'm not seeing anything obvious to fix this in the commit.
>
> Thanks,
>
> James
>
>
> On 5 August 2015 at 10:04, James Green <james.mk.green@gmail.com> wrote:
>
>> We're using to - i.e. a producer. ..to(http4:some.host) and some.host gets
>> all the headers in the request.
>>
>>
>> On 5 August 2015 at 09:57, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>>
>>> Hi
>>>
>>> Yeah the http filter was filtering only for the producer. We should do
>>> it for the consumer as well, so camel-jetty etc do not include Camel
>>> headers in the http responses by default.
>>>
>>> There is plenty of options already we should not add more.
>>>
>>> I logged a ticket to let the http filter strategy filter those for
>>> both the producer and consumer
>>> https://issues.apache.org/jira/browse/CAMEL-9052
>>>
>>>
>>>
>>> On Wed, Aug 5, 2015 at 9:51 AM, James Green <james.mk.green@gmail.com>
>>> wrote:
>>> > We recently had cause to tcpdump an http request from the http4
>>> component
>>> > to a web site. We were most surprised to find a load of exchange headers
>>> > listed as HTTP "header: value" pairs.
>>> >
>>> > A quick search on-line brings up a couple of Red Hat / Fuse documents
>>> > saying that headers named 'Camel...' are not transmitted onwards, others
>>> > are.
>>> >
>>> > Two concerns:
>>> >
>>> > 1. We see no documentation concerning this on the http4 component's page
>>> > 2. There may be a great many applications deployed unintentionally
>>> > transmitting internal headers to third parties potentially in breach of
>>> > policy or legal restrictions without human knowledge
>>> >
>>> > I suggest adding a new option, CopyAllHeadersToHttpHeaders, defaulted to
>>> > false. This would allow developers to "correct" their applications
>>> without
>>> > code changes, and those taking advantage of this facility can switch it
>>> on
>>> > explicitly.
>>> >
>>> > This isn't a Camel security vulnerability but I very much expect it to
>>> be
>>> > leading to information leakage "out there". It is certainly not a
>>> behaviour
>>> > we expected to see given the documentation. There may be other
>>> components
>>> > that require similar attention.
>>> >
>>> > Thoughts?
>>> >
>>> > James
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2nd edition: http://www.manning.com/ibsen2
>>>
>>
>>



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2nd edition: http://www.manning.com/ibsen2

Mime
View raw message