Typically, any server side variable initialized by a user input should be properly escaped before being written in the page.
Escaping depends on the context:
- escape tags for HTML injection,
Fields stored inside the Nuxeo Platform and that may contain HTML/JS that could be integrated inside a page should be escaped.
For that, the Nuxeo Platform provide a built-in sanitizer that is plugged to a Core EventListener: it can be run to check / escape content each time a field is updated.
This is controlled by
HtmlSanitizerService. You can use the
sanitizer extension point to define what fields you want to be automatically sanitized.
When the data directly comes from a parameter of the request (or similar), the data must be properly escaped.
If you want to do the escaping on the pure server side, in Java, you can use
In FreeMarker you can use the two built-in escapes:
Thanks to the JSF ViewState management, all active (POST) requests have to be associated with a correct (non guessable) ViewState id : this makes a built-in CSRF protection.
Automation API is by default exposed via JAX-RS and it does not include any specific filtering related to CSRF.
However, the Binding extension point of AutomationServer allows to define filtering rules on a per Operation basis.
In addition, most CSRF issues are related to users having valid authentication sessions : a simple protection can be to limit access to REST API to some specific authentication methods. Typically, you can easily define a custom Authentication chain that will be dedicated to REST Calls : this is actually the case by default with a configuration like :
<specificAuthenticationChain name="Automation"> <urlPatterns> <url>(.*)/automation.*</url> </urlPatterns> <replacementChain> <plugin>AUTOMATION_BASIC_AUTH</plugin> <plugin>ANONYMOUS_AUTH</plugin> </replacementChain> </specificAuthenticationChain>
Using a similar approach to can restrict this authenticator to "safe authenticators" like the Nuxeo Token Authentication.
NB : This is not done by default to avoid creating compatibility issues.
Alternatively, we are working on adding a dedicated filter that will allow to define more specific filters on API calls (see NXP-13644).