Forum Discussion

Jeroen_Steenkam's avatar
Jeroen_Steenkam
Icon for Nimbostratus rankNimbostratus
Feb 06, 2019

v13.1 How to overrule an ASM_RESPONSE_VIOLATION of attack type ATTACK_TYPE_INFORMATION_LEAKAGE

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.

 

  • Allowed HTTP codes can only be added globally in the security policy (and automatically applies to all URIs and all source IP addresses).
  • Source IP addresses can be whitelisted, but will bypass the whole ASM module.
  • iRule: ASM:unblock is not supported in ASM_RESPONSE_VIOLATION event.

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.

 

1 Reply

  • 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