chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Brown" <jay.br...@us.ibm.com>
Subject Re: Security related question
Date Thu, 18 Aug 2016 19:50:08 GMT

Emrul,

Thank you for the feedback.  Since you are knee-deep in this right now,
would you consider writing up a paragraph or so (with code snippets, if
needed) to describe your (verified) work-around while it is still fresh in
your mind?

If so, Florian and I can add it to the server development guide :
https://github.com/cmisdocs/ServerDevelopmentGuideV2/blob/master/docs/OpenCMIS%20Server%20Development%20Guide%20-%202nd%20Edition.pdf?raw=true



Jay Brown
Senior Engineer, ECM Development
IBM Software Group



From:	Emrul Islam <emrul@emrul.com>
To:	dev@chemistry.apache.org
Date:	08/18/2016 08:30 AM
Subject:	Re: Security related question



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 <fmui@apache.org> 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).




Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message