External AEM POST Requests renders Content Modified Response

[#1]

Hello Everyone,

Apologies, the same query has been raised sometime back but having some additional queries. if anyone could give any insights, it would be really helpful.

Request:

POST / HTTP/1.1
Host: www.xyz.com (changed)
Transfer-Encoding: chunked
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) 
Content-Length: 4
Content-Type: application/json

0

Response: Content modified /content/xyz

Status	200
Message	OK
Location	xyz
Parent Location	/cotent/xyz
Path	/content/xyz
Referer
ChangeLog	<pre></pre>

Modified Resource 

Parent of Modified Resource 

The above post request(from any third part client like postman etc.) does not modify any thing on AEM however it gives the directory information and a view that something has been modified. 

Due to some requirements we can not block the post requests at dispatcher level as well as through referrer filters in AEM.

Apart from filtering and identifying the POST requests at dispatcher level (allow or deny), Is there any other way to handle it? (it should not show 200 with content modified message)

Also if we can modify the default response of such post requests  (i believe it is through default SlingPostServlet)? 

[VKumar20 · Accepted solution]

Are you attempting to block POST's on AEM Author or AEM Publish? 

If you are trying to block POST's on AEM Author, don't 🙂 .. AEM uses POSTS and especially those handled by the Sling Default POST servlet liberally. Blocking anything that isn't a POST to a very specific URL is asking to break AEM's OOTB functionalities. You should instead, use ACLs to control what content/content trees an AEM Author can write to via the POSTs (which will result in a 403, not a 200 if the user does not have permissions to write to the target path)

If you are trying to block POST's on AEM Publish. The pattern to do this at AEM Dispatcher is:

1. Deny everything

2. Allow only POSTs for the specific paths/path-patterns you know are required for your application

3. Ensure that your content on AEM Publish is properly protected by ACLs, so any POSTs you DO allow ensure the right ppl are modifying the content.

If you are properly filtering out (DENY'ing) these POST requests at Dispatcher, you will not get a 200, but rather a 404.

[VKumar20 · Accepted solution]

Thanks @davidjgonzalezzzz for your inputs. We need to block POST requests on publisher(live) from the external sources. Having one doubt like If we put only 'Deny everything' for POST requests on dispatcher , will it make impact on internal registered servlets (by path and resource types)? Will the servlets(registered by path) filter out by this setting unless we configure the allow setting for specific paths in dispatcher. (slightly having doubt between internal and external post requests handling)

[#4]

The best practice to secure AEM Publish endpoints via Dispatcher is to:

1. First Deny EVERYTHING

2. Then Allow only what you need to 

This is why the first rule in the OOTB AEM Publish Dispatcher is "DENY *" [1]

In terms of identifying what URL end-points need to be ALLOWED in Dispatcher for POST'ing depends on your application's design. Hopefully custom POST end-points are bound to servlets registered to Servlets by Resource Type and Selector/Extension, and the resource that has the respective sling:resourceType's are permissioned accordingly.

If you actually use SlingPostServlet in your application on AEM Publish, then you would want to ensure that POST requests without any selectors, etc. are ONLY available on the content trees that should be written to using the SlingPostServlet, and those resources are permissions properly so only expected users can write to them.

Generally speaking, I would be concerned if any user that isn't admin has write access to /content (not sure if your original example was just an example).

[1] https://github.com/adobe/aem-project-archetype/blob/master/src/main/archetype/dispatcher.ams/src/con...

[#5]

@VKumar20,

If you are referring to a Sling Servlet from AEM, You would probably need to review the business logic. Amend the doPost() method to check for necessary acceptable values. If acceptable values are not matched, you can return your own custom status, for example, 406 NOT ACCEPTABLE.

I am actually assuming that your doPost method returns a "XXX" (whatever your servlet is setting as the response status) status as the response, on every request.

Example Code to Implement 406 HTTP Response:

@Override
protected void doPost(SlingHttpServletRequest request, SlingHttpServletResponse response) throws ServletException, IOException {
    if (request.getParameter("test") == null) {
        response.setStatus(org.eclipse.jetty.http.HttpStatus.NOT_ACCEPTABLE_406);
    }
    // your logic
}