Dispatcher Security - .feed extension

Avatar

Avatar

Brett_Birschba1

Avatar

Brett_Birschba1

Brett_Birschba1

30-07-2019

Reference Adobe Docs at: Configuring Dispatcher

AEM docs have a rule that “prevents content grabbing” where the feed selector is prevented for extensions json, xml, and html.

# Deny content grabbing for /content and its subtree
/0082 {
/type "deny"
/path "/content/*"
/selectors '(feed|rss|pages|languages|blueprint|infinity|tidy)'
/extension '(json|xml|html)'
}

Docs also indicate that the following URLs should all be blocked by your configuration:

/content/add_valid_path_to_a_page/_jcr_content.feed
/content/add_valid_path_to_a_page/jcr:content.feed
/content/add_valid_path_to_a_page/pagename._jcr_content.feed
/content/add_valid_path_to_a_page/pagename.jcr:content.feed

However, dispatcher configs for content grabbing are not blocking those URLs b/c .feed is the extension. Adding to the confusion, it seems that all of the following page URLs return the same thing:

- /en.feed.html (blocked by dispatcher rule)
- /en.feed (allowed by dispatcher rule)
- /en._jcr_content.feed (allowed by dispatcher rule)

Adobe dispatcher rule blocks the selector, but not the extension, even though both return the exact same thing.  I'm also curious about the `_jcr_content` / `jcr:content` selector to understand what that triggers and if that should be blocked.

Can someone help me make heads/tails about what should be blocked and what shouldnt be blocked?

Accepted Solutions (1)

Accepted Solutions (1)

Avatar

Avatar

andyshreve

Avatar

andyshreve

andyshreve

30-07-2019

It's good to harden the dispatcher to block content grabbing requests because they can expose the architecture of your site and overload your server. Without this kind of hardening at your dispatcher, a crafted request could fetch all your content or expose your source code. The .feed extension can expose areas of your site you might want hidden so it's good to just block it. Blocking _jcr_content or jcr:content is more of a judgement call that depends on how your site works. For example, you might have a component that performs an AJAX request for resources located beneath a page's jcr:content node, so in that case you wouldn't want to block those requests. Below are some selectors it would be wise to block with your dispatcher:

.blubber.

.blueprint.

.docview.

.feed.

.infinity.

.languages.

.pages.

.query.

.rss.

.scaffolding.

.sitemap.

.sysview.

.tidy.

.wfsummary.

Answers (3)

Answers (3)

Avatar

Avatar

Jörg_Hoh

Employee

Total Posts

(val/1000)?string[".0"]}K

Likes

891

Correct Answer

(val/1000)?string[".0"]}K

Avatar

Jörg_Hoh

Employee

Total Posts

(val/1000)?string[".0"]}K

Likes

891

Correct Answer

(val/1000)?string[".0"]}K
Jörg_Hoh
Employee

31-07-2019

Please report the missing selectors to Adobe support, so the documentation can be augmented. Thanks!

Avatar

Avatar

andyshreve

Avatar

andyshreve

andyshreve

31-07-2019

Documentation should serve as a starting point even though it can be incorrect or incomplete. Sample code provided online is rarely production-ready, and in this case you'll want to write a deny configuration for the feed extension. The documentation lists paths that should be blocked, so you may need to write configuration to block those at a minimum. The other selectors I listed that aren't documented were Adobe ones I've seen over the last 7 years which may or may not still be supported. I haven't seen _jcr_content or jcr:content used as selectors, so maybe someone from Adobe can speak to that.

Avatar

Avatar

Brett_Birschba1

Avatar

Brett_Birschba1

Brett_Birschba1

31-07-2019

Thanks @andyshreve I completely agree with you on the point about blocking content grabbing.  My confusion is that the rule that Adobe docs provide is insufficient to do so.  There are some selectors you have above that are not covered by it.  And though the rule blocks the .feed. selector, it does not block the .feed extension which appears to return the same thing.  Thoughts?

Also, any idea what the `_jcr_content` / `jcr:content` selector actually does?  I know you can put those tokens in a path to fetch the content node or its children directly, but never seen it in the selector portion of the URL.