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.br...@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 <em...@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 <f...@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). > > > > >
