chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <f...@apache.org>
Subject Re: Security related question
Date Fri, 19 Aug 2016 14:30:30 GMT
Hi,

I've added some more code and comments around authentication.
Among other things, I added two CallContextHandlers that support 
UserPrincipals and simplify the use of custom authentication filters. I 
also made the CallContextHandler work for WebServices. That is, all 
bindings can now use the same authentication methods.


- Florian


> Hi Jay,
> 
> Yes - absolutely happy to do that.  I'll wait until I have verified my
> work-around more thoroughly but should be able to provide a 
> documentation
> update over the weekend.
> 
> Thanks
> 
> On Thu, Aug 18, 2016 at 8:50 PM, Jay Brown <jay.brown@us.ibm.com> 
> wrote:
> 
>> 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
>> 
>> [image: Inactive hide details for Emrul Islam ---08/18/2016 08:30:50
>> AM---Hi Florian I understand the considerations here and accept 
>> th]Emrul
>> Islam ---08/18/2016 08:30:50 AM---Hi Florian I understand the
>> considerations here and accept that most usages will
>> 
>> 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
View raw message