cancel
Showing results for 
Search instead for 
Did you mean: 

Why is multiple content-length headers not reject by stingray traffic manager?

SOLVED
Highlighted
New Contributor

Why is multiple content-length headers not reject by stingray traffic manager?

Vulnerability :

Apache Tomcat Multiple Content Length Headers Information Disclosure

Vulnerability.


Load Balancer Version : Stingray 500 L2 9.4


Question :

We have tomcat (v 7.0.54) nodes running behind an Stingray load balancer. During a Qualys scan of the LB virtual server, we found it has an "Apache tomcat multiple content length header information disclosure" security vulnerability.

What happens is that when an HTTP request comes to Stingray LB with multiple Content-Length headers it should ideally return an HTTP 400 Bad Request but instead it is returning an HTTP 200 OK response. This is being reported as an "Apache tomcat multiple content length header information disclosure" security vulnerability.


We have confirmed using curl that this vulnerability is not because of the backend tomcats nodes. So it must be Stingray LB which is eating one of the Content-Length headers and passing only one to backend tomcat nodes.


Is there a way for us to let Stingray simply pass on all Content-Length headers to tomcat nodes without any changes and when HTTP 400 is returned from backend tomcat, stingray LB also returns it back to client.

8 REPLIES
Occasional Contributor

Re: Why is multiple content-length headers not reject by stingray traffic manager?

We're having this problem too, and let me add that the application firewall doesn't have a profile option that does something like counting and/or discarding extra content-length headers, so it's really not clear what Stingray/SteelApp is doing here.  I think a little more visibility would be great.

I also tried a TrafficScript request rule attempting detect requests with too many Content-Length headers, but I haven't had any luck.

Contributor

Re: Why is multiple content-length headers not reject by stingray traffic manager?

i've tried to make a similar request on our site, without success. pls post your curl-test, my test was:

curl -H "Content-Length: 100" -H "Content-Length: 200" http:/myserver

and it ended in a "bad request"

New Contributor

Re: Why is multiple content-length headers not reject by stingray traffic manager?

Load Balancer Version : Stingray 500 L2 9.4

Hey Jochen, thanks for your reply.

We are using following curl command, same as Qualys scan used :

curl -v -k -H "Content-Length: 0" -H "Content-Length: 0" https://myserver

Here, we are passing content-length as 0 because Qualys scan also passed content-length as 0 and used https protocol to access      myserver.

For this, LB returns "200 OK" message instead of returning "400 Bad Request" error. And due to this we are facing "Apache Tomcat Multiple Content Length Headers Information Disclosure Vulnerability" issue.

New Contributor

Re: Why is multiple content-length headers not reject by stingray traffic manager?

Hi Ambi,

I looked into this for you. The SteelApp Traffic Manager does indeed check for duplicate 'Content-Length' headers. If found, and their values differ, then the STM will return a 400 Bad Request. However if duplicate Content-Length headers are found, and their values are the same, then the STM will still allow the request, forwarding only one of the duplicate headers to the back-end.

As the tests you are running send multiple 'Content-Length' headers with the same value (0), the traffic manager would be allowing the request. I'm assuming this is enough to trigger the warning you are seeing.

I hope this answer helps. Please don't hesitate to let us know if this doesn't fully answer your question.

Regards,

James

New Contributor

Re: Why is multiple content-length headers not reject by stingray traffic manager?

Load Balancer Version : Stingray 500 L2 9.4

Hey James, thanks for your reply.

When we send request with 2 Content-Length headers with same value then Stingray Traffic Manager returns a HTTP "200 OK".

Qualys scan consider such requests a "Vulnerability" and we need to fix it for PCI compliance.

Interestingly when we passed 3 Content-Length headers with same value STM returned a “400 Bad Request”.

Only when we pass multiple content-length with different values then STM it returns a "400 Bad Request".

New Contributor

Re: Why is multiple content-length headers not reject by stingray traffic manager?

Hi Ambi,

The behaviour you're observing is completely acceptable according to RFC 7230:

   If a message is received that has multiple Content-Length header

   fields with field-values consisting of the same decimal value, or a

   single Content-Length header field with a field value containing a

   list of identical decimal values (e.g., "Content-Length: 42, 42"),

   indicating that duplicate Content-Length header fields have been

   generated or combined by an upstream message processor, then the

   recipient MUST either reject the message as invalid or replace the

   duplicated field-values with a single valid Content-Length field

   containing that decimal value prior to determining the message body

   length or forwarding the message.

Furthermore, it seems that the test that the Qualys scan is using to check for the vulnerability is not completely valid. The vulnerability you mention requires that the 2 Content-Length headers have different values to be effective.  See https://www.owasp.org/index.php/HTTP_Request_Smuggling (Example 1) for more information.  In any case, the STM will never pass on duplicate Content-Length headers.

Altering the current behaviour within the STM would likely adversely affect other customers, so we are reluctant to make any changes in this respect.

Regards,

James

New Contributor

Re: Why is multiple content-length headers not reject by stingray traffic manager?

Hi Ambi,

Just to summarise this issue for you. The current behaviour of the STM when receiving an HTTP message with multiple content length headers is as follows:

  • If there is 1 content-length header, forward the message as normal.

  • If there are 2 content-length headers:

       • If both content-length headers are the same, strip one of the headers and forward the message as normal.

       • If the content-length header values differ, then return a 400 to the client.

  • If there are more than 2 content-length headers, return a 400 to the client.

The Traffic Manager will never forward a request with multiple 'Content-Length' headers downstream. The headers are always cleaned up first, before any other internal processing. This is why it is not possible at this point to write a TrafficScript rule to detect this situation -- the request has already been sanitized before being fed into the TrafficScript VM.

We would encourage you to report this false positive to Qualys, and to ask them to correct their test. The method they are using at the moment is enough to detect a version of Tomcat that is vulnerable to the issue, but unfortunately does not accurately detect the presence of the vulnerability itself.

Please don't hesitate to let us know if there is any further information we can provide.

Regards,

James

New Contributor

Re: Why is multiple content-length headers not reject by stingray traffic manager?

Hey James,

Thank you so much for your very detailed information about the behavior of STM when receiving an HTTP message with multiple content length headers.