Hi,
I am wondering if anyone knows ways to block requests to AEM servlets ? There are attacks to servlets registered at paths say /bin with parameters that are invalid leading to query within the system
i can think of ways to validate the values and then let the process but should we move to options like registering by sling resource types to avoid attacks or block domains via dispatcher or so ?
does registering servlet via resource type for GET method help avert security vulnerability ?
seeking ideas
regards,
Solved! Go to Solution.
Views
Replies
Total Likes
What we have in our project is protection against this kind of attack at AKAMAI, if there are many request from same IP in a short time, we block the IP/user.(There are policies to handle this kind of securities measures at Load balancer or at CDN level)
Yes change to resource type will not help, but it is a best practice to register servlet using resourceType instead of Path.
registering a servlet thru resourceType is always a best practice as you can easily manage the access to that content but sometime we need to have servlet registered with path in such a case you can secure it on dispatcher filter.
Hope this helps
Umesh Thakur
@Rohit_Utreja @Umesh_Thakur Thanks, i literally think of proceeding with resourcetype but wouldn't this lead to the same issue knowing that that resource type for instance is accessible with query params will be passed, and read access is allowed? Unless ofcourse suggestion is to use service resolver via system user account?
@Rohit_Utreja @Umesh_Thakur thank you both for your inputs..
It is recommended to use sling servlet by resource type.
But, in some case we do need to use a servlet by path based on the use-case. In this case,
When a servlet has been registered by resource type, AEM's OOTB access control mechanism plays a critical role.
Whereas, when registered a servlet by path, security is the major concern. However, AEM provides multiple security features including CSRF protection.
Besides servlets, you should also protect pages if someone hits them with query parameters.
In this case, DDoS protection and other blocking requests can be helpful.
To avoid hitting the publisher if someone uses query param, you can handle this by removing query param for undesire urls using Apache rewrite rules.
@arunpatidar Thanks, but in this case, we do have query params and the security concern is unwanted values in query params leading to query traversal. i can think of validating the query param coming in prior to request being processed but is there any other way?
You can't check anything else as part of request. Everything else can be forged/mimik to make those requests.
Better to implement DDOS protection (Block IPs if there are many request in short time of frame)
@arunpatidar thanks.. when you say implement DDOS, is it blocking IPs and domains that you speak of post monitoring? Kindly provide an eg if you have
Also, i dont believe the change to resource type will help, would it?
What we have in our project is protection against this kind of attack at AKAMAI, if there are many request from same IP in a short time, we block the IP/user.(There are policies to handle this kind of securities measures at Load balancer or at CDN level)
Yes change to resource type will not help, but it is a best practice to register servlet using resourceType instead of Path.
Thank you @arunpatidar for confirming my understanding