security #token :  The subscription panel didn't work because it used the old code on the user profiles. To fix this error, the panel uses now the new user profile service based upon AngularJS and it is updated to take in charge the use of promises to chain asynchronous computations
security #token :  Adding the library CSRFGuard to manage synchronizer tokens
security #token :  Refine the session opening in Silvepeas when authenticating a use. The refinement is based upon the assumption that in JEE, each incoming request is associated with a session. When a user logon to Silverpeas, an HTTP session is already existing and this session is then reused as the user specific session once the authentication succeed and it is the set up with some attributes (main controller, ...). If the user had already an opened session with Silverpeas during the autentication process, then this session is no more closed and it is reused as such
security #token :  Pass to version 1.2.3 of AngularJS (previously 1.2.2). Fix an error with the user panel when the selection is only on users (discovered when selecting a validator for a publication in creation). Fix also an error with the comment JQuery-based plugin that used the old silverpeas-profile js; it uses now the one based upon angularjs.
security #token :  Remove the use of the OWASP CSRFGuard library as it doesn't work well and there is no answer to our fix. So we are starting to implement our own security token (synchronizer token) by inspiring ourself on the way it is implemented by CSRFGuard. Before starting to implement our own security token solution, the existing token API in Silverpeas is refined in order to accept other than persistent tokens. The persistent tokens are generated for some types of resources in Silverpeas in order to access them or to access some contents in Silverpeas authorized by the token; currently, such tokens are only used for users to access Silverpeas without passing by any required authentication mechanism. The refinement of this API is now done.
security #token :  Add Java package information and add a new token type: the synchronizer token
security #token :  Add a mechanism to set a synchronizer token for each HTTP session created for an authenticated user, and to validate it when a protected web resources are accessed. The web resources are protected according to some rules defined in the org/silverpeas/util/security.properties file in the form of a regexp; any web resources whose the path doesn't match the rules aren't protected by the synchronizer tokens. In order to be valid/trusted, a request to a protected resource requires to be stamped with the synchronizer tokens. For doing, a javascript code, generated from the template tokenSetting_js.st, is executed in the client side to update the AJAX requests, the form submission, and the anchor with the synchronizer tokens expected by the targeted web resource. Because of the strong use of deprecrated frames and of redirection (and mainly of double or more redirections), not all works correctly at this time; some work is again needed to set correctly the tokens for each request.
security #token :  Externalize the rules indicating the web resources to protect with a synchronizer token( by their path) in the property file security.properties. The security mechanism can be also disabled with a parameter in this file.
Use now a cookie to pass the synchronizer token used to protect the user session as a workaround of the many use of the relocations and of the frames that complexify the web conversation. The cookie is created once a session is opened.
Add a new class, HttRequest, to decore the HttpServletRequest with additional functions and with overriding methods. This class provides useful and high level functions. Now this class is used in the request routers instead of the HttpServletRequest. This class provides also directly the fetching of parameters from a multipart stream by using the FileUploadUtil methods.
security #token :  The WYSIWYG editor takes into account also the request attributes when a request forward is performed within the web container (between two servlets) so the use of intermediate JSP for just to redirect automatically to the htmlEditor.jsp aren't more necessary and must be avoided; the use of such redirection doesn't work with the synchronizer token mechanism because it hasn't the time to update the form used for the redirection with the token
security #token :  Now the rule to use to protect the web resources in Silverpeas without impacting the proper functioning of the platform is hard-coded. Add some descriptions about the servlet filters in the web.xml descriptor.
security #token :  Refine the use of the synchronizer token to protect a user session when using functions on the credential management. In this case, the user isn't nessecary authentified and the web page needs to be protected against some attack technics like the fuzzing. So, in order to use the synchronizer token to protect the web pages on the credential management, a token is created automatically at each session opening by the web container (so the synchronizer token can be used with anonymous navigation). (This token is then renewed once the user is authentified.) Some administration functions are again vulnerable to CSRF and XSS attacks because of the use of a cookie to carry the synchronizer token (the use of a such cookie is mandatory currently in Silverpeas because of the deep use of frames and of multi-relocation requesting), so it was necessary to explicitly protect these functions and thus to break regrettably the centralization and the generalization of the token management code. The anonymous access was also tested and some bugs fixed