AEM Security - .json Extension

[BrettBirschbach]

In AEM we generally block all `page.infinity.json` and `page.N.json` requests, as it allows content grabbing and reveals internal node structure including usernames or anything else that might be considered "internal". However, page.json requests (no selector) seem to also render their JSON contents, and this is a lot harder to block unless we generically block the .json extension, requiring all valid JSON URLs to be whitelisted.

Is there a way to safely block JSON rendering to close this vulnerability?  Or do we just have to accept that anyone can freely grab your internal node structure and private content such as usernames?  The idea of blocking `.json` ubiquitously, opening up for only a whitelisted set of URLs is tempting to see as an easy solution, but that makes servlets based on resource types rather than static URLs infeasible.

NOTE: I understand that JSON rendering by sling can be turned off in "Apache Sling GET Servlet" in OSGi, but then that breaks other OOTB functionalities related to personalization where calls to `/home/users/X/XXXXXXXXX.infinity.json` based on the current user are used.

[vipins5188 · Accepted solution]

Hi Brett,

You can write custom sling filter servlet to stop execution of such request. For example pageinfo.json calls "/libs/wcm/core/content/pageinfo.json" request.

/**
* Simple servlet filter component that blocks requests for page information.
*/
@SlingFilter(generateComponent = false, generateService = true, order = -500, scope = SlingFilterScope.REQUEST)

@Properties({ @Property(name = "sling.filter.pattern", value = "/libs/wcm/core/content/pageinfo.json") })

@Component(immediate = true, metatype = false)

public class XYZFilter implements Filter {

}

Override doFilter method and add your custom logic to block request based on http referer or your internal/external environment host name.

Hope this helps.

Thanks,

Vipin

[Kunal_Gaba_]

One option for you is to block all .json URLs and whitelist the ones which should be allowed. If you have any resource type based servlets then you could register them with a custom selector along with JSON extension.

[BrettBirschbach]

Heh thanks kunal23​ I do realize we could technically use a custom selector to get around the issue of whitelisting.  It's definitely a workable solution, and thus I appreciate you confirming.

That said, given that this is a security issue, shouldn't AEM have a solution that doesn't require custom development?

[BrettBirschbach]

Thanks vipins5188​ I'll take a look at your solution and see if that will be a clean solve.  I'd rather do this if possible rather than require all JSON requests to have a whitelisted selector since the latter seems arbitrary.

It does raise a question, however, about why Adobe doesn't solve this issue of being insecure by default.  Was hoping maybe there was some setting that I was just missing.

[Jörg_Hoh]

You cannot block the ".json" extension by default on publish instances. Because there often are custom servlets, which are using this extension, and you would block them as well.

What you can do is to disable the JSON Extension on the Sling Default Get Servlet [1] on publisih. By default then you cannot request any resource with the JSON anymore, which is often acceptable.

If you think that the AEM default should be changed for publishs, please report to Adobe Support. (I think it should change!)

Jörg

[1] localhost:4502/system/console/configMgr/org.apache.sling.servlets.get.DefaultGetServlet

[BrettBirschbach]

vipins5188​ What is the purpose of the sling filter pattern of `/libs/wcm/core/content/pageinfo.json`?  The JSON I believe comes from the Apache Sling GET Servlet which listens to "resource type" of `sling/servlet/default` - should the filter be more broad to capture all requests that would be handled by the GET servlet?

[BrettBirschbach]

Hey Joerg, I definitely thought of that, but disabling JSON rendering in the Apache Sling GET Servlet breaks other OOTB functionalities related to personalization where calls to `/home/users/X/XXXXXXXXX.infinity.json` based on the current user are used.

[stephanief27724]

Thanks

[Jörg_Hoh]

Hi Brett,

if that's your usecase: Yes, you cannot disable it then. On the other hand side you have authenticated users then, and probably you can implement functionality to reject all JSON requests from the anonymous user on publish.

[vipins5188]

Hi Brett,

I gave pageinfo.json just for example purpose here, you can have any path from the request. Purpose here is to get control over that request and serve it to specific audience and and specific content/data.  Plus thiats sling filter with filter pattern value so it won't effect your default servlet things

[BrettBirschbach]

Ok, sounds good, thanks!