Tag Archives: AEM Security

AEM Security: How to secure the AEM application?

Overview

There is a set security practice followed by every development team in Adobe experience manager ( i.e AEM) CMS technology. And, Most of these are pretty straightforward suggested by the Adobe as best practices however there are many other security issues which have equal importance.

So, Let’s begin to know how to secure your application by putting right rules in your AEM environment.

All other recommendations from the open web application security project(i.e OWASP) should be applied. Below recommendations are very specific to AEM technology & AEM infrastructure.

There are many problems which are unknown to the AEM Solution provider & putting the whole thing at risk. I would like to state one of the examples here to showcase the security problems in AEM.

Use below Google Query to find out if your author instance is indexed by the google or not. I have used a very basic query in google. Try it, you would surprise to see how many author instances which are open to exploits. You might be wondering how to login in those authors. That is fairly easy once you know who has authored the pages.

Google Query: inurl:aemauthor

AEM Author Security:

First & foremost, Make sure your AEM author instance isn’t searchable by the search engine & It is not accessible outside of Intranet without VPN. Follow some author security guidelines below:

  • Keep robots.txt for all your domains including the authoring environment. make sure Google does not index author domain.
  • Enable HTTPS in AEM Author.
  • Changing Admin password in every AEM instance (i.e server).
  • Create groups for assigning access & follow the least privilege principle. Basically, Instead of denying on many hierarchies just allow what individual group needs.
  • Create a separate replication user to use in replication agent configuration. Admin should not be used for replicating anywhere.
  • Limit the number of users in admin groups.
  • Web dev, CRX explorer & CRXDE in prod author should be disabled or should be limited to certain users.

AEM Publish Security

Same as AEM author, publish instances should not be accessible to an outside of the intranet & connections to web servers, author etc should be internal connections. The most important thing to handle in publish security is to handle requests inputs & use proper request sessions. Serving requests with admin session or privileged user is a big problem. 

Assume some data you have to read & anonymous user does not have permission to that then avoid using admin session. Have a dedicated user for that to read/write the content for certain requests. Follow other guidelines respect with AEM Publish security:

  • Anonymous permissions should be checked & make sure not every directory accessible to the anonymous user. Even in etc design, There should be proper permission setup in cloud services etc.
  • Apache Sling Referrer Filter must be configured to handle unwanted publish requests.
  • The cross-site forgery framework should be enabled to filter requests.
  • All default tools (Crx explorer, Crxde, WebDev) etc should be disabled.
  • No one should be able to access publish server directly. Also should not be able to install packages directly.

Dispatcher security

When anyone thinks of AEM security, most of us just think of rules & filters in dispatcher.any configuration file. But, There are many more use cases where things are not pretty if you have not taken care of security:

  • Do not have dispatcher flush agent configured from AEM author. And if it is enabled then have https call for flushing cache. Otherwise, author flush agent exposes to your web server IP & credentials.
  • Limit the request headers information. Request headers are passed in every request to AEM publish based on dispatcher configuration.
  • Do not allow cross-origin requests. Set the SAME origin header at the web server level.
  • Proper input validation should be done in POST Requests & dispatcher filter should allow only certain POST requests.
  • Caching of selectors & URL extensions should be defined. Not every selector or extension should be cacheable. DOS or DDOS attacks are very easy to do in AEM application.
  • Website URL’s should not expose internal directories.

Final thought

We have to secure the infrastructure & security of important environments. Once you have security author, publish & proper dispatcher configuration, you would have a better chance to protect your application. Application security is another aspect follow the below links for Adobe recommendation.

Web Security: How to use third-party javascript securely

In Security of WebApps, we often think of securing our database, application server security & other frameworks security like Structs, Spring etc. Generally, Frameworks are the first point of target for the hackers because it provides straight entry into the target application. But, the situation has been changed a little bit. These frameworks are getting more secure day by day. And hackers are targeting low hanging fruits.

The more vulnerable piece of software in any web application could be your fancy third-party javascript. Javascript is actually bad for security but very powerful language. And, one of the core issue & feature with Javascript is that it is flexible & does not require whole programming stuff like Java or Python. It executes within the browser, easy minimum code & easily injectable in many ways: Through Forms, Review comments, Web service response etc.

Hackers do not need to hack your server & network to steal your information. One or two lines of javascript could be good enough.

Hacking through Javascript

Following problems may happen using third-party libraries:

  • Third-party javascript will have access to the application as your own javascript.
  • Malicious javascript code. Third-party libraries has been compromised.
  • Confidentiality, Integrity etc are other security risks.

Most of the applications use third parties, open source javascript libraries to implement some functionalities. And, hardly anybody knows who maintain, fix bugs in these open source libraries. Even if we buy javascript libraries, Hardly there is any security testing done on those frameworks. Hackers use third-party & integrated services to break the target application. The recent example is here.

The British Airways Hack: JavaScript Weakness Pin-pointed Through Time-lining

How to secure our application when you have used third-party javascript?

About Open Source Libraries: Open source libraries are great & provide so much fancy javascript stuff. However, the major concern is that we never know what changes have been updated & how those are affected to your application. Someone can add malicious code & will wait for you to get the latest changes loaded in your application.

Solution-1

General practice is that keep them in the source code & use them. Do not depend on patch & updates regularly from the owner of these libraries. It is one way to add security to our application. Let’s assume you want to upgrade these libraries to get some latest features or bug fixes then plan just like you plan for any software update. Do not just copy paste minified version.

Not every third-party javascript can be party of your source code. For those situation try solution-2.

Solution-2

Another way is to keep relying on libraries hosted by third-party. In the case of analytics, DTM scripts are generally loaded from third-parties. However, the point is that make sure security testing do the diligent work. Use some JavaScript specific security tools like Javascript security analyzers. These tools perform code analysis on client-side applications.

Final Thought

This seems very small step & do not get much attention. We all try to solve big problems first. But, In my opinion, these small issues solve the bigger problem & control much more damage than building a new rocket. For suggestion or inputs, leave your comments. Thanks.