List all possible selectors and extensions for denial of service (DoS) attack mitigation

[25793466]

Under the guidance of the security checklist (Security Checklist​:  "Incorporate controls at the application level; Control the selectors in your application"), how would I determine all possible extensions and selectors that are running in my instance?

[arunpatidar]

Hi,

I am not sure, if this is possible or not but there is other way to implementing guard against DDoS attack , please check this, if helps.

The Excessive Selector Removal Filter is aimed at increasing security for sling/CQ/AEM instances wit...

Thanks

Arun

[wimsymons]

When you architect and implement your application, you know exactly which selectors you use, so it should not be rocket science to only allow those selectors in the dispatcher filter rules.

The idea is to whitelist only what is needed. By default AEM allows for example to export your entire content tree as JSON. That on itself would require so much resources you would kill your instance.

[25793466]

Right.  I know from that perspective.  Our deployment has one package that I wrote, so I know our selectors.  But I can imagine an application, perhaps poorly architected, that has many code packages where a developer might introduce a selector that could cause problems.  It would be nice to query them from an administrative perspective to ensure compliance.

And what about the out-of-the-box ones?  I am assuming only the .html (Apache Sling Servlet/Script Resolver and Error Handler) and .json (Apache Sling GET Servlet) extensions are available.  What about default selectors?

This is all really a theoretical exercise for what can be done on the publish instance.  In practice, we completely lock down our application through the dispatcher.  Only .html files on our content paths are supported.  No selectors on .html.  No .json either.  We even lock down assets (js, css) to specific paths and disable all selectors except for minify.

[Jörg_Hoh · Accepted solution]

This approach does not work, because you can come up even with non-existing selectors which you need to block as well. Therefor you should switch from a blacklist approach (deny things which you know you don't use) to a whitelist approach (deny everything but allow the things you need).

In that case it would mean, that you should come up with a ruleset, which starts with a "deny all" and then allow all selectors you use. That should be doable if you have an application which rarely uses selectors at all. It becomes hard if you use many selectors and nearly impossible when you don't know the selectors, because they are kind of dynamic (and unknown to development time).

Still, this is a flawed approach too. Because if someone really wants to take you out of business, that person will just run a DOS against your site, not exploiting your application at all, but rather saturating the network pipes (that's a service you can probably get on some darknet marketplaces). In that case a careful locked application does not help you, because enduser requests hardly ever reach your application, but get stuck somewhere between the enduser and your servers.

And if that someone tries hard enough, you have to throw many many resources  (that means: $$$$) at it to mitigate such attacks.

Therefor I see the security checklist not as a way to protect your AEM from begin DOSed, but rather to avoid the leakage of sensitive data, which shouldn't get exposed. The only DOS you should be aware of is the regular traffic coming in from the users of your site.

kind regards,

Jörg

[25793466]

We do deny everything first.  The first line of our dispatcher.any filter section is: /0001 { /type "deny" /glob "*" }

Since there are several other sections of the security checklist devoted to the dispatcher, I thought this particular section ("Incorporate controls at the application level; Control the selectors in your application") was implying something additional can be done within the app as well.  I'm just trying to be thorough.