For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

AskingQuestion_'s avatar
AskingQuestion_
Icon for Nimbostratus rankNimbostratus
Nov 09, 2015

What is the reason HTTP Status 500 defined as an illegal http status in response in ASM?

We have an application generating status 500 code, which was defined as illegal http status in response by ASM. By reading some information, it seems that ASM defines 4xx - 5xx all as illegal by def...
ASM Advanced WAF
security
Pablo_Lalloni_3's avatar
Pablo_Lalloni_3
Icon for Nimbostratus rankNimbostratus
Apr 11, 2018

I'm sorry to revive this old thread but the issue is being revisited by our team right now.

 

Of course leaking sensitive details is a big problem and must be avoided, but that doesn't mean that http status code 5xx are leaking such details.

 

Applications should be programmed and/or configured to catch unexpected errors and transform them to 5xx responses with some opaque content allowing to refer to the issue in some way so the event can be related to appropriate log entries to be diagnosed and fixed.

 

But the 5xx status code should reach the client so it can act accordingly.

 

Otherwise the client is tricked receiving a 200 response with a completely unexpected content which causes lots of headaches.

 

Pablo_Lalloni_3's avatar
Pablo_Lalloni_3
Icon for Nimbostratus rankNimbostratus
Apr 15, 2018

Problem is, our server code correctly informs a 5xx code with a response body having a secure error report which is supposed to be used client side to render a user friendly report with an error id for calling the help desk.

 

The 5xx has the semantic specifically needed, it's not a server "crash" (it's not a request problem, as a 4xx status code means; it's not a redirect, it's a server side reason for not responding as requested as the HTTP protocol is supposed to report).

 

The problem is: what should be blocked is insecure content like stack traces with infrastructure details and such, but not blindly breaking the http protocol by replacing a meaningful response with an unexpected, empty, OK response.

 

Returning a 2xx code in place of a 5xx is particularly harmful because what should have been an error is transformed to a non-error but with unexpected content. This has many unwanted and problematic consequences such as:

 

  • The 2xx could be potentially cached downstream, which make the problem durable! A 5xx error is supposed to get fixed server side, so the http components between between client and server would never know the cached borked response should be retried.
  • The client receives a 2xx so, following protocol semantics, it assumes the server sent what it asked but, bam!, it didn't, it gets something else and when it tries to treat it like the expected content you've got a lot of weird and dark errors.

Also 403 has other meaning as per the spec.