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 Wed, 17 Aug 2016 15:30:32 GMT
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