Joerg Kessler created CAMEL-9807:
------------------------------------
Summary: 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
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)
