Security-centric Enduser application enabled with CSRF / XSRF and CAPTCHA
Apache Syncope 2.0 brings a whole set of enhancements and new features, among which there is undoubtedly the Enduser application.
The scope of Apache Syncope Enduser is primarily to provide a dedicated web-based application for self-registration, self-service and password reset; up to Syncope 1.2, such features are built into the admin console but, as we have learned from experience, customers require to heavily customize not only the appearance but often the actual mechanisms behind, in order to best suit their processes and flows.
This is the main reason why Enduser is composed of AngularJS frontend - which eases extension an full customization - and Apache Wicket backend - which proxies access to Syncope core, thus skipping several security concerns at a glance.
The introduction of a client-side technology as AngularJS brought some important security issues to attention; above all, CRSF / XSRF and bot attacks.
CSRF / XSRF protection
CSRF / XSRF, e.g. cross-site request forgery, also known as one-click attack or session riding, is a type of malicious exploit of a website where unauthorized commands are transmitted from an user that the website trusts.
Several techniques are available to face CSRF (including honeypot, e.g. hidden form fields holding token values which are expected to match POST requests), but Syncope Enduser relies on advanced AngularJS security features, based on XSRF-TOKEN.
The mechanism is simple yet powerful: the Wicket-based backend sends a random unique token value in the XSRF-TOKEN session cookie, as part of one of the first HTTP GET request received by the AngularJs-based frontend; $http, the client-side service managing HTTP requests, in turn, reads the value of the XSRF-TOKEN session cookie and sets the X-XSRF-TOKEN HTTP header accordingly, for all XHR requests. At this point the backend has all means to reasonably check, for each request, that the caller is the expected one by matching the token value in session with the one received.
The reliability of this approach consists in the fact that, since only the code running on user's domain could read the XSRF-TOKEN cookie, the Enduser backend is assured that the XHR request came from a trusted domain. The HTTP header cannot be set for cross-domain requests because all browsers provide the same policy origin feature, preventing other origins (different from user's one) to read current session-cookies; even if a X-XSRF-TOKEN HTTP header is set from malicious origins, it must anyway match the value provided by Enduser backend.
Do I have necessarily to use the CSRF / XSRF protection on my own Enduser deployment?
Not necessarily: you can enable or disable this feature by configuration.
BOT protection
Usually, application for self-registration as Syncope Enduser are meant to be public and available to anonymous, thus exposed to malicious attacks, such as DoS (Denial Of Service) or DDos (Distributed Denial Of Service), that make network resource unavailable to its intended users, such as to temporarily or indefinitely interrupt or suspend services of a host connected to the Internet. This malicious entity in the worst case is a BOT, a software application that runs automated tasks (on the Internet).
CAPTCHA has been recognized as a valid protection against this kind of attacks.
The Apache Syncope Enduser provides this feature, enabled by default, as last step of self-registration or self-update. The backend implementation relies on Apache Wicket CAPTCHA which is powerful enough, but based on traditional CAPTCHA-by-image.
Can I embed Google re-Captcha in my own Enduser deployment?
Yes. But it's not provided by default because it requires the application registration with an associated Google account.
Do I have necessarily to use Apache Wicket CAPTCHA in my own Enduser deployment?
Not necessarily: you can enable or disable this feature by configuration.
Yes, Excellent! 