Skip to main content

Adobe

How Good is your AEM Security? – AEMaaCS and 3rd Party Dependencies

AEM dispatcher security

Large scale data breaches and critical security vulnerabilities have companies thinking about security more than ever.  Many developers are familiar with the OWASP top 10 (https://owasp.org/www-project-top-ten/).  There are already many resources on generic mitigation for these vulnerabilities.  So instead, in this series, I cover security issues and mitigations specific to AEM.  In this final post, I will cover the Content Disposition Filter, changes in AEM as a Cloud Service, and 3rd party dependencies.

Previous posts in series:

Content Disposition Filter

If you allow users to upload SVG images to your site, you might be creating a vulnerability.  Viewing a user-uploaded SVG image directly via URL is subject to a XSS attack since these images can also contain malicious JavaScript.  Typically this JavaScript is constructed by a bad actor to either send user cookies and storage data to a remote server or create a legitimate looking page for phishing purposes.  Malicious users could then link this file stored on your server to unsuspecting victims, which would come from your domain.  From a security perspective, it’s preferable to disallow SVG uploads at all or at least programmatically remove all JS from the SVG files before saving them server-side.  If this is not possible within your business requirements or too large of a scope, there’s another solution that will help.

The Content Disposition Filter in AEM https://experienceleague.adobe.com/docs/experience-manager-64/administering/security/content-disposition-filter.html?lang=en is generally used to control whether assets accessed directly in AEM are displayed in the browser or downloaded.  In this case, you could configure it to always ask users to download SVG images when linked on your site, instead of rendering in the browser.

This will reduce the effectiveness of the malicious JavaScript in two ways.  One is that hopefully users will be more wary of downloading files than just viewing content rendered directly in the browser.  The second is that if you have properly configured CORS to not allow localhost, the downloaded malicious script will not be able to load several site resources as it will no longer be requesting them from your domain.  This hinders the malicious attempt of dressing up the SVG resource as a legitimate site page.  It’s important to note, this doesn’t cover all scenarios, but it’s an easy and quick configuration change within AEM.

AEM as a Cloud Service

In AEM as a Cloud Service (AEMaaCS), several of the potential vulnerabilities discussed in this series are no longer possible thanks to some key architecture changes.

  • AEMaaCS receives regular, automatic patches from Adobe rather than requiring a manual update process by the implementation team.
  • The /apps and /libs path are now immutable. You must redeploy the entire instance through Cloud Manager.
    • This makes some persistent XSS techniques (e.g. writing JSP pages to the JCR) and JCR-based remote code execution no longer possible.
    • You will still need to update dispatcher rulesets within your application codebase if there are any further Sling resolution vulnerabilities found.
  • The previous OSGI web console is now inaccessible.
  • User-generated content is generally not handled through direct writes to the JCR.
    • This can lower the chance of persistent XSS because the resources are no longer directly accessible via Sling.
    • You will still need to incorporate write type, permissions, and rate limits within your services that write to a database.
  • Your application code must pass Adobe’s SonarQube ruleset before it can be deployed, which catches some vulnerabilities before they make it to QA and Prod.

So while these changes help significantly, there’s still a lot of work to do to make sure your AEM instance is secure.

3rd Party Dependencies

After 5 weeks of security posts, there’s still a key security topic I haven’t discussed, and it’s one of the easiest to miss.  It’s also arguably the most likely for malicious actors to target.  That is 3rd party application and platform dependencies.  Malicious actors tend to focus on these libraries and frameworks for a few reasons.  One is that the code is typically open source, which is easier to search for vulnerabilities than your black-box application.  Another is the vulnerabilities are exploitable in multiple applications instead of just one, leading to higher payouts.

Let’s examine a well-known hack as an example of how bad this can get.  In May-July 2017 Equifax was hacked, resulting in one of the biggest data breaches in history.  Attackers stole names, addresses, Social Security numbers, birth dates for around 143 million people.  The vulnerability?  It wasn’t in the application codebase, but in an insecure dependent version of Apache Struts.

Code reviews, automated code scanning, and application best practices were not sufficient to catch this type of issue.  If, in addition, the Equifax team had kept up to date with the Struts security patch released months earlier on March 7th, the breach could have been avoided or greatly limited.

Thus my recommendations are as follows:

  • Choose 3rd party dependencies have security reviews, widespread adoption, and an active development community.
  • Have a scheduled intake process in place for critical AEM and 3rd party security patches.  Make it a priority to test and install them.
  • Utilize an automated application dependency scanner like FOSSA. It’s a lot easier to run these scans once or twice a week versus manually checking all dependencies.
  • Write automated security tests (unit and functional) along with your regular test cases.

That’s all for now, thank you for joining me on this security series.  If you enjoyed this type of content and would like to see more on AEM security, I’d love to hear from you.  For more information on how Perficient can help you achieve your AEM Security goals and implement your dream digital experiences,

Contact Perficient to start your journey.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Paul Goodrich

Paul Goodrich is a certified Adobe Experience Manager Technical Architect at Perficient. He is committed to excellent customer software experiences, complex problem solving and optimizing Agile delivery.

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram