Posts tagged "DoS attacks"

May 17, 2013

Page level selectors validation to prevent DoS Attacks

In the Adobe CQ security checklist located at https://dev.day.com/docs/en/cq/current/deploying/security_checklist.html, Denial of Service (DoS) Attacks prevention was briefly touched on. In this blog post I am going to give an example on how to best handle selectors validation at the CQ page level.

As mentioned in the security checklist, one of the most commonly seen Denial of Service attacks targeting CQ is by requesting a content page with unlimited number of URLs. Without selectors validation, these page requests are then usually cached, causing the disks to fill up very quickly and bring down the service.

Remember the Apache Sling script resolution? A script may have the following form (see http://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html):

{selectorStringPath}.{requestExtension}.{scriptExtension}

Imagine I have a valid CQ page test.html, here are the few variations I can have for the same page:

test.xyz.html
test.abc.html
test.aaa.html
test.bbb.html
test.abcde.html

All these would be valid pages (if without checking the selectors) and would be cached in the cache layer if configured so.

The best way to prevent the above is to do a validation of the selectors at the page level. Sling API, specifically the RequestPathInfo, provides the getSelectors() method to get all the selectors from the requested URL. If you are not expecting any selectors being passed to your CQ page, you should make sure that slingRequest.getRequestPathInfo().getSelectors() yield an empty array. Otherwise, you should do a very strict comparison of the selectors array with what you’re expecting.

If there’s any unexpected selectors, you may choose to throw a 404 (Not Found) or other error status code so that the page does not get cached.

 

Note that the above would only prevent invalid requests from being cached. These requests, although not cached, would still be routed all the way to the CQ servers (another means of DoS attacks is to generate massive number of requests to a targeted server). So another highly recommended line of defense, is to set up very strict dispatcher filter rules so that invalid requests would not generate any traffic to the CQ servers.

 

9:31 PM Permalink