camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-9807) Blocking of CXF consumer endpoint by http GET request
Date Mon, 04 Apr 2016 12:12:25 GMT

     [ https://issues.apache.org/jira/browse/CAMEL-9807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Claus Ibsen updated CAMEL-9807:
-------------------------------
    Fix Version/s: 2.18.0
                   2.17.1
                   2.16.4

> Blocking of CXF consumer endpoint by http GET request
> -----------------------------------------------------
>
>                 Key: CAMEL-9807
>                 URL: https://issues.apache.org/jira/browse/CAMEL-9807
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-cxf
>    Affects Versions: 2.16.2
>            Reporter: Joerg Kessler
>            Priority: Critical
>             Fix For: 2.16.4, 2.17.1, 2.18.0
>
>         Attachments: CXFTypeConverter.patch
>
>
> Hi,
> by chance we found a problem that can create a security risk. The scenario is a CXF WS
consumer endpoint configured without WSDL and right after that a step, e.g. a setHeader that
uses an XPath to access the CXF payload. When you now create a http GET request on the endpoint
(normally it should be POST) then the error No type converter available to convert from type:
org.apache.camel.component.cxf.converter.CachedCxfPayload to the required type: javax.xml.transform.sax.SAXSource
with value org.apache.camel.component.cxf.converter.CachedCxfPayload@45812dad
> is thrown.
> First of all it is surprising that CXF accepts the request. Second a type conversion
like that is possible. The reason for this error message is within the type converter coding.
The converter returns a null object for the not existing payload of the GET request but this
is interpreted as there is no type converter available. One could say that this is just a
bad error message but more over the type converter is now kind of black-listed internally.
That means the next calls being correct or wrong will not look for a type converter but return
immedeately the above error. That means the endpoint is blocked until the scenario is restarted.
This seems to be more efficient than a DOS attack (but of course one has to have access rights).
I provide a simple patch that raises a runtime exception in the CXF type converter when there
is no payload. I am not 100% sure whether this is the best way to fix it. Maybe GET requests
should be blocked already in CXF. I also could imagine that somethin like that is also possible
in other components. 
> We use Camel 2.16.2 and I tested it in CXF 2.16.3 and it is not fixed.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message