Security Measures in AEM Development
Author: Lavanya Manoharan
Introduction:
Security of an application starts in the development phase. In this article we will see the security measures that should be taken while coding and while doing the configuration. Some of the security vulnerabilities considered in this article are:
Cross-Site-Scripting (XSS): These attacks happen when the attacker injects executable scripts into the web through the inputs provided for the user or by modifying the request to perform malicious action on the website.
Denial-of-Service (DoS): This type of attack makes the website inaccessible by sending numerous requests to the website, so that the function of the website will interrupt, and the website will be unavailable for the intended users.
Cross-Site Request Forgery (CSRF): This is an attack impersonating an authorized user to execute unwanted, privileged actions on the website.
Below are some of the common security measures that should be taken while coding and configuring AEM.
Security measures while coding:
· For servlets use the ‘resourceType’ instead of ‘path’ so that the sling engine will manage the permission.
· While getting user entered data from request parameters, always validate the data to prevent it from XSS attack. We can make use of XSSAPI to filter the user entered data — below are some examples:
import org.apache.sling.xss.XSSAPI;
@Reference
XSSAPI xssapi;
//example1
String param = xssapi.filterHTML(request.getParameter(PARAM_1));
//example2
jsonString = xssapi.getValidJSON(jsonString,”defaulValue”);In the example1 ‘filterHTML’ will filter the user-entered html and return the sanitized html and in the example2 ‘getValidJSON‘ will validate the JSON if it’s not valid then a default value will be returned. After filtering the data by using the appropriate method of XSSAPI we can perform required functionalities on the data.
· In Sightly we have default XSS protection in the framework, as it automatically escapes the client scripts. Sometimes we have the requirement to include styles or scripts, and in those cases we can declare the context:
${properties.styles @ context= ‘styleString’}
${properties.script @ context= ‘scriptString’}The above examples include a CSS string and JavaScript, and declaring the context will allow the specific functionality. Review the documentation for available context options.
Avoid using “context = unsafe” in sightly code for user entered data, as it disables the XSS protection and makes the code prone to XSS and other attacks.
Required configuration changes:
· Servlets in AEM have added security measures which include the sling referrer filter and CSRF protection framework.
1. sling referrer filter: In this configuration, disabling the ‘Allow empty’ property will filter out requests without the referrer. We can add the list of allowed hosts in the ‘Allow Hosts’ property, so only requests from those hosts will be allowed. Through the ‘Filter Methods’ property we can also configure the methods that must be filtered.
2. CSRF protection framework: This framework generates a token to prevent CSRF attack, using tokens to make sure that the client request is legitimate.
For the CSRF token, we must add the category “granite.jquery” or “granite.csrf.standalone” in clientlibrary. For the form, whenever the request is sent to the client the token is generated and validated when it’s sent back to the server. The token will be generated only for authenticated users.
Using “Adobe Granite CSRF Servlet” we can change the validity of the token; the default is 600 seconds.
In CSRF filter we can configure which methods should be validated and we can add the safe user agents which will not be filtered and the paths which should not be filtered using “Adobe Granite CSRF Filter”
For this CSRF token to work we must allow the CSRF token endpoint “/libs/granite/csrf/token.json” in the dispatcher and also we have to replicate the HMAC binary to all the instances. Refer to CSRF protection framework.
It can be used for POST, PUT, and DELETE methods, but not required for GET and anonymous requests.
3. Same Site Cookie: Same site cookie prevents from CSRF attack by the control of the cookies to the third-party site. In AEM we have “Adobe Granite Token Authentication Handler” with SameSite attribute for login token cookie.
In this SameSite attribute we have three values which are Lax, Strict and None.
Lax: Default value of SameSite attribute is “Lax” which provides moderate security against CSRF attack by allowing the cookies only if there is a safe method like GET.
Strict: In this setting, the login cookie will be sent only for the same-site request.
None: If we have any requirement to send the cookies cross site then we can set “None” to the SameSite attribute. This setting is only applied if the protocol is secured (HTTPS).
4. Some of the ways to prevent DoS attack:
· Disable the unused default renderers in “Apache Sling GET Servlet” — some of the internal details might be exposed if we don’t disable.
For example, if we have enabled the HTML default renderer then we are able to access the folder under the dam as html with below details.
Don’t disable the JSON renderer as it is required for normal AEM functionality.
It is necessary that the dispatcher is configured to deny access to everything and allow access only to the required requests to ensure sensitive information (e.g. username, password…) or the huge informations (e.g. infinity.json, infinity.tidy.json…) cannot be retrieved via public URLs.
In dispatcher, you can also filter the request without the referrer and only allow known selectors and suffixes, so when an attacker requests URLs with different selectors or suffixes, the server will return 403 or 404 status responses. Since the response is not 200 those responses won’t be cached, preventing overloading the disk space.
