Hi Experts,
I am using AEM 6.3 for a project, and I have received a finding from the penetration test team saying that they can access some internal details.
For example if they access http://localhost:4502/content/dam/we-retail/en/activities.html (activities is a folder) they can see some internal information.
Is there any way to disable this default html rendering for some resource type (ex sling:folder)
Thanks and Regards
Denny
Solved! Go to Solution.
Denny,
I found something and I validated on my local instance(AEM 6.2). Basically, when we enable a renderer for GET servlet, we see this behavior. Surprisingly, I see a whole lot of live sites having this issue and worst thing is these pages are getting indexed by google and showing up in search results.
Anyway, there is a OSGI configuration in felix console which needs to be tweaked to fix this issue. Please follow these steps
1) Please go to felix console's configuration manager http://<hostname:<port>/system/console/configMgr
2) Go to Apache Sling GET Servlet and edit the configuration values
3) You will see a "Enable HTML" option , if the check box is checked/selected, it means that you are enabling the HTML renderer for the default GET servlet and that produces the result you are currently witnessing.
4) Disable(unselect the check-box) this option and try it again, you should see an expected 404 page instead of the "Resource dumped by HtmlRendererServlet" message.
By default, I was not getting this error/message on my local instance, but I reproduced it by enabling the "Enable HTML" option
Hope this helps!!
I guess it is the default behavior of sling. Meaning, when we do not have a script or sling:resourceTtype associated with a node, this page is displayed also this happens when we have an invalid sling:resourceType. They are like the bad nodes or pages which can be cleaned up. But in this case you are noticing the behavior on a sling:folder type(not on a cq:Page or a component). Is this an upgraded environment? and is this behavior seen only for given set of folders or are you seeing it for other types as well??
Please check whether or not all the required bundles are active.
Also, generally it is recommend to remove all the OOTB (geometrixx and its related) code, configs, content from higher environments. I believe we-retail is one of the OOTB package.
Views
Replies
Total Likes
They have access to this node - check permissions
Views
Replies
Total Likes
Hi,
Why do you have sling:folder nodes in your node hierarchy below /content? I would expect here only cq:page, jcr:content or nt:unstructured nodes, but never a sling:folder node.
You cannot change the node type, but maybe you can add a "sling:resourcetype" property to it and apply a custom rendering. Otherwise register a servlet to the resource type "sling/folder" and the extension "html", then you can handle the rendering of such folders in your own code.
Jörg
Views
Replies
Total Likes
Views
Replies
Total Likes
Hi Jörg Hoh
The sling:folder is created under the asset folder /content/dam/we-retail/en/activities (ie when you create a folder using DAM console).
Can you please tell me how can i register a servlet to sling:folder?
Regards
Denny
Views
Replies
Total Likes
Denny,
I found something and I validated on my local instance(AEM 6.2). Basically, when we enable a renderer for GET servlet, we see this behavior. Surprisingly, I see a whole lot of live sites having this issue and worst thing is these pages are getting indexed by google and showing up in search results.
Anyway, there is a OSGI configuration in felix console which needs to be tweaked to fix this issue. Please follow these steps
1) Please go to felix console's configuration manager http://<hostname:<port>/system/console/configMgr
2) Go to Apache Sling GET Servlet and edit the configuration values
3) You will see a "Enable HTML" option , if the check box is checked/selected, it means that you are enabling the HTML renderer for the default GET servlet and that produces the result you are currently witnessing.
4) Disable(unselect the check-box) this option and try it again, you should see an expected 404 page instead of the "Resource dumped by HtmlRendererServlet" message.
By default, I was not getting this error/message on my local instance, but I reproduced it by enabling the "Enable HTML" option
Hope this helps!!
That's of the course a better solution than I proposed. I never had the need to turn this feature on, so I was a bit puzzled to this strange behaviour.
Jörg
Views
Replies
Total Likes
Views
Likes
Replies