security.stx

ACASUserFolder and Security

This section is designed for users with high security needs rather than features, mainly for internet public access.

It's Session based

User credentials are stored in the Zope session into a protected container. Zope guru's may stop reading here :-)

In other words, if M. malicious steal the _ZopeId cookie of a CAS connected user jack, it will be really easy to steal jack identity by setting M. malicious browser _ZopeId cookie to the jack one value.

Then a very simple solution to avoid this is to use Zope behind an https frontend. There are plenty of Howto's out there describing this. With https, _ZopeId cookie will be safely protected.

However BrowserId methods other than _ZopeId cookie may be used and then ACASUserFolder will take advantage of any improvement of newer methods.

Note: with usual BasicAuth, security is even worse, because the user password is sent in clear on each browser request.

Session protection

On the Zope server side, user credentials are stored in a container which accessor methods begins with _. Such names are not accessible from DTML or ZPT, so it's a reasonable protection level.

Be aware that the best protection is to disallow ZPT & DTML modifications rights from non trusted users, or to be very careful on which extentions are installed.

POST data handling and potential DoS

ACASUserFolder use a specific method for handling POST data.

POST data cannot be forwarded the same way GET data is via the URL. And by its nature, POST data may represent a big amount of data.

So ACASUserFolder store POST data in the protected session container. It will be reinjected in the request after CAS (re)authentication success.

Note: Files uploaded with POST method are currently discarded because they are not pickleable.

To achieve this, we have to create a brand new session for an Anonymous user. Because after session timeout, the session no more exists and CAS credentials are lost. So the current user posting data is Anonymous, and we have to trust him in the current implementation. If the user already has a BrowserId (_ZopeId cookie) it will be reused, otherwise a new one will be generated.

Then M. malicious may blast the server with forged POST request with a different _ZopeId cookie each time and quickly exhaust the maximum number of sessions allowed.

For this reazon, a management option allow to disable this feature.

Note1: when there are no free sessions, the server is perfectly working. But no new CAS users can connect. Anonymous users may not be affected if your applications do not use session (this is often the case). Admin users using Basic Auth are not affected too. The situation will return to normal after SESSION_TIMEOUT minutes after the DoS has stopped.

Note2: this has been implemented this way to use transient container for POST data and avoid transactions to be comitted on disk storage. Any comments on this are welcome.

Author & Maintainer

Alexandre SAUVE < mr .dot. lex -at- free .dot. fr >