Dispatcher and Sling Servlet ignores POST configuration

[josiahh39572999]

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.

[wimsymons]

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.

[josiahh39572999]

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.

[wimsymons]

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.

[Jörg_Hoh]

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

[josiahh39572999]

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.

[josiahh39572999]

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.

[Jörg_Hoh]

what version of the dispatcher are you using? IIS or Apache httpd based?

Jörg

[josiahh39572999]

I'm using the module for Apache 2.4 .

[Jörg_Hoh]

Can you share the exact version number as well?

[josiahh39572999]

Ah yes no problem:

Dispatcher 4.3.1

Apache 2.4.35

[josiahh94050133]

Hello again Jörg.

Have you had a chance to look into this issue further?

[Jörg_Hoh]

I checked and it looks to me that the code itself throws a 404 in that occassion. Although I don't know what's happening on your side. Can you increase the loglevel of the apache httpd as well and check them?

Jörg

[josiahh94050133]

Hi Jörg.

When I hit the publisher directly now with a POST, I am getting a 403 forbidden for any page as expected.

The only change made was to disable contexthub read access for the "everyone" group. I have yet to determine how that could possible affect this.

In any case, after verifying the publisher, I re-attempted the POST request at the Dispatcher layer. I was still able to receive a 200 at that layer. So I added the following update in our main apache configuration file, to block the POSTs before they reach the Dispatcher.

<IfModule mod_rewrite.c>

     RewriteCond %{REQUEST_METHOD} POST

     RewriteCond %{REQUEST_URI} !/path/to/a/bin/servlet

     RewriteRule .* - [F,L]

</IfModule>

It seems to be working well.

My only remaining question is, will this break requests to Sling POST servlets which are binding only by resource type and/or extension?

[Jörg_Hoh]

The dispatcher does not know anything about servlets or resource types. In the snippet you posted you allow all POST requests not matching this condition. So these requests will pass dispatcher and get forwarded to AEM; and there they are handled no matter if the servlet is bound by path or resource type.

Jörg

[josiahh94050133]

The rewrite conditions in the above snippet are denying POSTs to any URI except a specific bin servlet (one which we want to allow content to be posted to) via use of the forbidden flag. The request processing ends at the Apache layer for these POSTs and doesn't make it back to AEM.

Since Apache HTTP server and its modules don't have any way of recognizing a Sling resource type, I was concerned that those rules will block legitimate POSTs back to a servlet which is only bound by resource type or extension.

Looking into this further though, I don't think this is an issue. If we have a content path that needs to be updated via POSTs, we can add it to the list of exceptions above and let Sling handle it via it's standard process for script resolution (relying on the content's sling:resourceType property to call the correct servlet).

With that, the main issue is resolved. I appreciate your insight and help with resolution!