CSRF Protection

Introduction

CSRF -or Cross-Site Request Forgery- is an attack where a malicious attacker makes a user’s browser to perform an unauthorized action on a trusted site for which the user is authenticated.

As the attacker has no way to receiver the command results, this attack is used to perform state-changing actions (i.e. changing a Product’s price) instead of simply fetching data. For a much more detailed discussion about this attack see CSRF Attack.

Starting from PR19Q1, both the Backoffice and the POS has protection against this type of attack. The approach followed in both cases consists of implementing the Synchronizer token pattern, which means that a random token is generated for each user session and this token should be sent along the state-modifying requests (POST, PUT and DELETE) to verify it comes from the user, which has access to this token.

Note that the generated CSRF token may change when there is a change in the User Session (i.e. when the user changes its role).

CSRF Protection in Backoffice

Standard Windows are protected against CSRF attacks out-of-the-box, both in grid and in form view.

The generated token is available in the client side in OB.User.csrfToken. This token is attached automatically to add/edit/remove operations and if not present, it will show a error message.

CSRF Protection in POS

POST requests sends automatically the User Session CSRF token as part of the request body. This token is also available in the client side in OB.MobileApp.model.get('csrfToken'). If the token verification fails, the server returns a 401 (Unauthorized) response.

There are 3 exceptions where it is not required to check the CSRF token although it is a POST request:

• It is a web service
• It is a stateless request
• A custom Authentication Manager is used and this requires that each request should be authenticated instead of relying on a Session.

For the latter case, the AuthenticationManager abstract class implements the method markRequestAsSelfAuthenticated(HttpServletRequest request) to make the server bypass the CSRF token check for this particular request.

These scenarios had been taken into account in the DefaultAuthenticationManager and the MobileKeyAuthenticationManager, but this should be taken into account when implementing a custom AuthenticationManager to avoid receiving 401 responses for not sending the CSRF Token.