The ASM module first scans the request for violations. Without violations the request is then forwarded to the webserver. Next, the ASM module scans the response for violations. Currently, HTTP Response code 500 will raise a blocking page.
One solution would be to create these conditions in a HTTP policy and enable different ASM security policies. But then we have to maintain another security policy or setup a new parent policy and two children that inherit all parent policy attributes. One child is able to decline the generic policy settings and allow response code 500.
What's the best practice to allow HTTP response code 500 for just a few URIs and/or source IP addresses, preferable within one security policy.
Allowing HTTP Response Code 500 to be returned to the client is a really bad design as it gives the potential attackers information on how to crash your application.
If you need to allow code 500 response for certain URLs then you can use ASM::disable in iRule
Thank you for your comments.
Our support department must be able to see the actual error message. We don't log responses on the F5, so we cannot see the error message based on blocking ID.
ASM:unblock only works on requests. Notice that the attack is a ASM_RESPONSE_VIOLATION.
The unblock command applies to requests only. It is not possible to unblock a response in which violations were found.
Hi Jeroen, I understand your requirements better now. So you need your Support team to see the error messages on 500 errors while you don't have response logging enabled on ASM. The solution here is to create a custom logging profile which will log responses on HTTP 500 responses ONLY and for specific URLs ONLY.
There is no point in whitelisting Support's IP addresses as surely the Support team will want to see the errors generated by all users and not just errors generated by the Support team (e.g. a 500 crash created by a user might not be replicable by the Support).
Alternatively you could capture any 500 response codes using an iRule and HTTP_RESPONSE event and log the error messages inside the iRule and then either rewrite the response as a redirect to a block page.