chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emrul Islam <>
Subject Re: Security related question
Date Thu, 18 Aug 2016 15:30:07 GMT
Hi Florian

I understand the considerations here and accept that most usages will
see a servlet filter to carry out authentication.  I still think a
documentation comment or similar would be really helpful because it is
an implementation detail that is not easily apparent - please consider
that as a suggestion.

For my use case its easy enough for me to patch my version of OpenCMIS
and move the token handling code earlier in the request processing
(which I can do because I don't need to read the body).  I also agree
that servlet filters are typically where this is done but it isn't an
option in my case since Servlet 3 Asynchronous processing doesn't play
well with servlet filters on all app servers - but that's unrelated to
the Chemistry project.

Thanks for your speedy reply!

On Wed, Aug 17, 2016 at 4:30 PM, Florian Müller <> wrote:
> Hi,
> You are right - with a few exceptions. ;-)
> In many (most?) environments the CMIS server is embedded into a DMS system
> or an application server or a cloud infrastructure or something similar,
> which does the authentication check before the request actually reaches the
> CMIS implementation. For a standalone CMIS server a Servlet filter is the
> preferred approach.
> There are many different authentication approaches; standard and proprietary
> approaches. If you can do the authentication by looking the request HTTP
> headers or checking a SSL client certificate, you should do that before the
> request hits OpenCMIS. That is, an unauthenticated request is rejected early
> and the request body is not read. But there are a few authentication methods
> and authentication rules that require reading the request body first,
> because the authentication information is in the body. For example, if the
> UsernameToken authentication is used in the Web Service binding the user
> name and password are in the body. A proprietary authentication method might
> check for a custom parameter that contains an additional secret or an
> application identifier or something similar.
> The body cannot be read twice. If you read the body in a filter, you break
> at least all CMIS calls that accept content. OpenCMIS has to read the body.
> To allow those authentication methods that require data from the body,
> OpenCMIS provides multiple places where those checks can be done with full
> access to the body. In this case you are right. Reading and managing the
> body consumes resources, which will be lost if the authentication is
> rejected. OpenCMIS makes sure that a malicious client cannot send an
> infinite stream of data, but if your resources are smaller than the built-in
> OpenCMIS limits you are in trouble. In the end it's up to the developers and
> operators if that is acceptable or not. I wouldn't do it.
> - Florian
>> Whilst working on a CMIS server implementation I happened to be
>> examining the CmisBrowserBindingServlet class and noticed that for
>> HTTP POST requests POSTHttpServletRequestWrapper is instantiated
>> before any authentication checks are carried out (e.g. before
>> getCallContextHandler() is invoked where a TokenHandler can check the
>> request).
>> POSTHttpServletRequestWrapper appears to process multi-part requests
>> as soon as it is created, getting an output stream to store data.
>> Unless I am mistaken (and forgive me if I am), it is conceivable that
>> this approach is vulnerable to Denial of Service attacks: you can send
>> a bunch of POST requests with multi-part data to the server that will
>> cause it to allocate memory (if less than memory threshold) and or
>> temp file space (if greater than memory threshold) and exhaust system
>> resources.
>> I would suggest that authentication should be checked before
>> processing multi-part requests in keeping with best practices (e.g.
>> rejecting unauthenticated requests as soon as possible).

View raw message