Is security in AEM a platform or implementation issue?

Posted by: Andrey Pinchuk | Certified Senior AEM Developer

Imagine the situation: you sleep peacefully and see your third dream, when suddenly a phone rings - a dissatisfied client complains that the whole system is unavailable. Agree, such events are discomfort for the life of the AEM developer, the entire team and the solution provider. There is nothing to be done, an early rise and a search for a solution ahead.

To prevent such unhappy moments from occurring in your professional life, I’ll tell you about typical security problems and how to better insure against them.

I will adhere to such a plan:

1. Security at Author level;
2. Publish level security;
3. Dispatcher Security
4. CSRF framework protection;
5. DDoS attacks.

Basic Adobe Experience Manager Security Tips

The world of AEM projects will become even better if each developer has a common understanding of how to protect the platform from data leakage as a whole. According to the diagram below, we have an author, several publishers and two or more dispatchers (the so-called balancers). In fact, these three levels are worth paying attention first of all in terms of data protection. These are the classic rules of work that are generally accepted in the AEM community around the world.

1. Use HTTPS . AEM is rapidly evolving, providing the flexibility to create an author on another, more secure protocol. It is enough to generate the “SSL Wizard” key, create a path to it and, thus, use a more secure protocol. In recommendations from Adobe - this step is precisely the first priority in security.

2. Install packages with the latest updates. The standard process of the developer comes down to the fact that when working on components and services, you have to look for solutions in Google. The goal of this step is to regularly monitor Service pack & Hot Fixes. Then a lot of problems go away, including those related to data safety. Although this is not a panacea, the important point is to keep the system up to date.

3. Creating neat pages with error messages. If you initially make a page with a brief description of the error, the client will immediately see that it is not working, while the developer will already be in the process of solving the problem. It is logical that this information will not pass by you, but you will avoid panic from the client and testers, confusion in the tasks.

4. Refuse to set a password and login on “admin-admin”. It would not be funny, but the problem with poor-quality login and password is quite common even in AEM. As a result, in pursuit of speed or other considerations, we get the most vulnerable system. Once you find that the primitive login details are set, try to convince the team / superiors and change them to more reliable ones as soon as possible.

Security at Author Level

First, use vpn . Using Virtual Protected Network is the work of a secure private network to establish a secure connection between you and the server. This is a simple and important tool: since your traffic will be encrypted, it is impossible to figure out where you are sending your data from. It turns out that with vPn no one will be able to access your instance.

This approach is suitable for remote developers and all those whose work is carried out from different locations with an unstable Internet connection.

Secondly, your “author” should always be closed, including from Google . So you can pick up a password and hack the system: by negligence, the author may be indexed. To check your vulnerability in a search engine, type in its line your domain and author and the path to crx. Yes, you can contact Yandex or Google with a request to delete such a line in the SERP. But while the issue is being resolved, the system will already be publicly available.

Thirdly, do not underestimate the privileges of the “admin” user , who most often has the ability to perform any available operations.

This is especially critical at the time when an employee says goodbye to the company. Indeed, for most businesses access to the instance is not personal, but through one administrator account. It is more logical to do the opposite and be aware of specific changes in the system from a specific author.

AEM 6.1 introduced a new approach where you can set specific rights for a bundle or user service. But it’s better to make a personalized profile: it’s pleasant for the employee, and it’s easier for the business to track who has what levels of access to the system. This approach is relevant for author and publisher levels.

Publish Security

As a rule, only after a long time on the project they notice that they did not check the anonymous user. And while an ordinary user may have restrictions on operations, an anonymous user - often happens, has much more rights to perform operations.

The Apache Sling Referrer filter is a convenient and effective mechanism to make your application secure. For example, send metrics to AEM, you see information on sending data in Inbox. If you exceed the default value, a third-party system may send this request. This means that anyone will not be able to send a request. You enter the domain into the configuration; at the time of the request, it compares it with the data originally entered and, if everything matches, the integration takes place.

It will turn out to carry out more flexible configuration with the filter: you can specify the request, method, host. Also there is an empty value or an asterisk for more detailed queries.

Security at the Dispatcher Level

Developers face dispute in 10% of cases. So, this is the main configuration file, where we set the type of URL (prohibit / allow).

Typically, developers do a small task, create a rule and forget that it will add vulnerability. So that no one tries to attack your instance, you need to check the url with selectors at the time of availability.

Through the configuration file, you can specify the processing of headers. Because the more accurately you specify the zag, method, etc., such a detailed setting will definitely not break anything. These are elementary examples. What if there are hundreds of such rules and navigating them is more difficult?

The easiest way is to enable logging. Depending on the version of Apache, the mechanism of work may change slightly. But the system will immediately highlight to you which url which particular rule is working out for you and what still needs to be corrected.

You can also specify domains in the rules: this is a reference to integration.

Once the dispatcher is used for caching, requests are many times faster: you don’t need to go anywhere and check, and you can immediately send it to the client. Plus, this method greatly improves the security of your application.

Cross Site Request Forgery - fake request.

General principle of CSRF: suppose you use your account on the bank’s website. After authorization, you have a standard session with cookies in the browser, you receive an email and follow the link to a suspicious site. On it, an attacker embedded a form, upon completion of which your data is sent to the bank's website.

The point is in the HTTP protocol. An attacker does not need a lot of data: this request is sufficient. The bank server will see: a request has arrived, there are cookies and a session, everything is all right. This is how typical attacks work.

What can AEM give to prevent query forgery

A classic example of protection is the generation of a "secret" in a string. When the form is generated, this secret token is added from the hidden field. If you go to the attacker's site, the system will detect the absence of a token or its invalidity and will refuse to send data. Sometimes they do protection from the users themselves.

Now you have a regular ajack, in which you can’t add a hidden field. At the authorization stage, the server returns a cookie with a name with SCRF to you, transfer it to the header, send it to the server. So you signed the request.

AEM will do everything for you: it will generate keys, tokens, it will check the form submission

There are cases when an application is written in React and there is a difficult moment with integration. AEM took this situation into account: just go to inpoint and sign it for verification. Suitable when using non-standard components and libraries.

What else can be done to protect the system:

• Libraries that are responsible for this. There is no sense in adding until you break anything.
• At the low level you can see all the “secrets". This is a kind of validation of your data.
• It's simple: there is a ready-made api and you are already protected from this type of attack.

DDOS attack - the second most popular attack

The goal is to exhaust the physical capabilities of the server. Millions of requests are being made on some host. When they become infinitely many, the system begins to physically not cope. As a rule, they attack powerfully from several sources and use a VPN. 100% of this is not insured; but let's not help them.

In which cases the system is vulnerable:

• Configure the system with the wrong suffix;
• There are a lot of requests for avs, the dispatcher on the public cannot forward them;
• When it is not forbidden to display an unlimited number of content nodes. In particular, the JSON renderer, which can cross the tree structure at several levels.
• localhost : 4502 / .json can dump the entire repository in JSON format.

To make your work on AEM safer, focus on the capabilities of specific users.

Do not forget to go through the Adobe Security Checklist , and let everything be stable with your project on AEM.