Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Are there any /bin/* urls that are at security risk in AEM?

Avatar

Level 2

I am allowing all of the URLs starting with /bin in my dispatcher setup. I am also using various servlets with different extensions (.txt, .xml). I found out that my dispatcher is exposing querybuilder's .json URL.  I have followed the dispatcher security checklist but it doesn't have the /bin/* URLs in the checklist. I am looking for a recommended approach for blocking /bin/* URLs.

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Blocking the url pattern "/bin/*" on author will break authoring functionality. But that's only true for authoring.

On publish requests should only happen to resourcetypes, thus only requests hitting "/content" plus maybe "/etc" should be necessary. That's also a reason why you should never bind servlets to paths directly: It will make your live much easier if you need to secure your instances.

Jörg

View solution in original post

7 Replies

Avatar

Level 3

Hi

The /bin folder is an empty one, and it does not contain any node default from AEM. It is given for the custom development just in case some developer wants to use it for there servlet. hence no security issue from default AEM perspective. But if you are planning to use it and add some stuff in it for internal use, you can block it on the dispatcher. else you can leave it as it does not contain anything.

Thx, Anuj

Avatar

Level 2

Hi Anuj,

though there are no nodes, I found that it http://localhost:4502/bin/querybuilder.json?path=/content_Path&type=cq:Page&p.limit=-1 this query builder's servlet was exposed over the dispatcher. I am looking for other servlets of AEM similar to query builder's servlet which are exposing data.

Avatar

Employee Advisor

As far as i know, most of the AEM servlets are being served from "/bin" Example:

http://localhost:4502/bin/wcmcommand

This is used whenever you perform any page related operations. So, I highly advise against blocking "/bin"

You should be allowing it as per the URL below as per the dispatcher configuration doc at [1]

/0022 { /type "allow" /url "/bin/*" }

[1] Configuring Dispatcher

Avatar

Level 2

Hi Jaydeep,

I believe requests like ​ http://localhost:4502/bin/wcmcommand​ are used internally by AEM and thus I want to block those request on dispatcher as I don't the user to access these internal requests via public URL. I do have the rule that you have mentioned but. I want to block all URLs other than my own servlets via dispatcher as I want to expose my servlet only on public URL.
I am looking for a standard approach/best practice. I had thought of serving all of my servlets via /bin/project_name/* then blocking /bin/* and later allowing /bin/project_name/* This will block all the servlets via bin except the /bin/project_name/ servlets. But I am not sure if this is a standard approach for servlets.

Avatar

Employee Advisor

If you are using dispatcher in front of the author, then you still need to allow "/bin" but for production publish instance the approach you mentioned looks good, block "/bin" and then allow project specific servlets.

That being said, still, I would recommend you perform testing to make sure there is no operation on publish instance that requires users to make a POST call to OOTB servlets under "/bin"

Avatar

Correct answer by
Employee Advisor

Blocking the url pattern "/bin/*" on author will break authoring functionality. But that's only true for authoring.

On publish requests should only happen to resourcetypes, thus only requests hitting "/content" plus maybe "/etc" should be necessary. That's also a reason why you should never bind servlets to paths directly: It will make your live much easier if you need to secure your instances.

Jörg

Avatar

Level 2

Thanks Joerg Hoh

I was asking the question for publish instance only. I will have to change my approach to resourcetype.