Highlighted

Dispatcher and Sling Servlet ignores POST configuration

josiahh39572999

24-11-2018

Hello.

When sending POST requests to content URLs in our production environment (AEM 6.3.3.1), I'm able to receive a 200 status response to the client.

This is despite the fact that I have the following rule in my dispatcher /filter configuration:

/0001 { /type "deny" /method "POST" /url "/content/*" }

I've also configured author and publish instances using the AEM security checklist (this environment is using production run modes with many development configurations disabled).

If I remove the .html extension in the POST, I receive a 403 status code response. So, I surmise that the 200 response is resulting from the way a Sling POST Servlet handles and delegates request processing to the default HTML rendering script(s).

After examining numerous configurations for request handling (referrer filter, default servlets, sling authentication handlers, etc.), I have yet to derive the reason as to why these POSTs are returning a 200. Ideally, if the POSTs are blocked, we should see the correct HTTP status code.

Is there something about the way Sling handles requests that I'm missing?

Are there any Adobe (or Apache Software Foundation) recommended pen testing tools for validating my dispatcher configuration?

Please advise.

Replies

Highlighted

wimsymons

25-11-2018

I would upgrade to the latest version of the AEM dispatcher first.

See AEM Dispatcher Release Notes .

If I remember correctly we had the same issue in an earlier version of the dispatcher.

About the testing tools, there is The Dispatcher Security Checklist and the dispatcher health checks in Operations Dashboard.

Highlighted

josiahh39572999

25-11-2018

Hi. Thank you for the reply.

I'm running on the latest dispatcher version 4.3.1, but I'm still seeing this issue.

Regarding testing tools, I followed the guidelines in the Dispatcher Security Checklist when I initially installed and configured the web server and dispatcher.

I'm also regularly monitoring the Operations Dashboards in the AEM instances.

Highlighted

wimsymons

25-11-2018

Have you tried following the best practice as described in https://helpx.adobe.com/experience-manager/dispatcher/using/dispatcher-configuration.html#Configurin... ?

I mean, deny access to everything in your first filter rule, and then gradually allowing access to whatever is needed?

If you deny access to everything all POSTs will be blocked.

Highlighted

Jörg_Hoh

Employee

25-11-2018

The above mentioned rule should prevent POST requests to /content/*; can you enable DEBUG logging on dispatcher, redo the request and post the log statements for this request?

Thanks,

Jörg

Highlighted

josiahh39572999

26-11-2018

Thank you again for the quick responses.

wimsymons​ - I do have a global deny set as the first rule in the /filter section:

/filter

/0001 { /type "deny" /glob "*" }

When I noticed the POSTs were returning a 200 status code, I added the following rule (below an allow rule using the GET method for the content path).

/0026 { /type "allow" /method "GET" /url "/content/*" }

/0027 { /type "deny" /method "POST" /url "/content/*" }

I assume the POST rule is redundant, with the global deny already in place.

Having that global deny rule in the dispatcher configuration is definitely a good practice though.

Jörg, when I check the dispatcher logs I see that the request is blocked (content path and domain generalized below):

[Mon Nov 26 10:49:33 2018] [D] [pid 83380 (tid 140589131982592)] Found farm website for somesite.com:8083

[Mon Nov 26 10:49:33 2018] [D] [pid 83380 (tid 140589131982592)] checking [/content/somesite/en.html]

[Mon Nov 26 10:49:33 2018] [D] [pid 83380 (tid 140589131982592)] request method is neither GET nor HEAD: POST

[Mon Nov 26 10:49:33 2018] [D] [pid 83380 (tid 140589131982592)] cache-action for [/content/somesite/en.html]: NONE

[Mon Nov 26 10:49:33 2018] [T] [pid 83380 (tid 140589131982592)] Filter rule entry /0027 blocked 'POST /content/somesite/en.html HTTP/1.1'

[Mon Nov 26 10:49:33 2018] [D] [pid 83380 (tid 140589131982592)] Filter rejects: POST /content/somesite/en.html HTTP/1.1

[Mon Nov 26 10:49:33 2018] [I] [pid 83380 (tid 140589131982592)] "POST /content/somesite/en.html" ! - 0ms [website/-]

So it would seem that even though the client receives a 200 status in the response, the filter rule is taking effect and preventing a write operation to the content.

I'm wondering why a 200 is still returned, is this just the way the dispatcher handles the response in the event of a blocked POST request?

The response body for the POST is the content page markup presented as if the request was using the GET method.

Highlighted

josiahh39572999

28-11-2018

Hello again.

Is there an answer regarding the below questions?

I'm wondering why a 200 is still returned, is this just the way the dispatcher handles the response in the event of a blocked POST request? Is this even a concern or can it be disregarded?

The response body for the POST is the content page markup presented as if the request was using the GET method.