Handle "Websocket-like" or other poorly compliant apps exceptions in ASM

Problem this snippet solves:

This code snippet can be used in ASM when you encounter an application that is not really compliant with RFC (hardly ever happens, right ? :) ), but you do not want to disable a blocking setting for the whole application.

I had to use it for an application which is doing some kind of WebSocket, but not really, some kind of RPC over HTTP but not really either... And was in fact sending some (non compliant) JSON in a payload of Content-Type: text/plain.

My ASM is protecting an APM published application. Which is why I also check for the MRH Session in the iRule. Not foolproof I know, but in this situation every little thing helps...

How to use this snippet:

  • Paste it in an irule on ASM that protect the dodgy application :)
  • Create the datagroup to list the URL for which you want to activate exceptions.
  • Remove the MRH Session check if you do not have an APM behind the ASM (or replace it with other checks that could give a hint that the applicative session is already established.

Code :

when ASM_REQUEST_DONE {
if { [class match $uri starts_with dg-uncompliant-urls] && [HTTP::cookie exists "MRHSession"] } {
        foreach asmviolation [ASM::violation names] {
            log local0. "DEBUG!! DETECTED VIOLATION : $asmviolation"
            if { $asmviolation equals "VIOLATION_OBJ_TYPE" || $asmviolation equals "VIOLATION_EVASION_DETECTED" || $asmviolation equals "VIOLATION_METACHAR_IN_DEF_PARAM" || $asmviolation equals "VIOLATION_MULTI_PART_PARAM_VAL"} {
                log local0. "DEBUG_EB!! ASM EXCEPTION BADAPP - ALLOW $uri - VIOLATION : $asmviolation"
                ASM::unblock
                }
             }
        }
}

Tested this on version:

13.0
Published Apr 12, 2019
Version 1.0
No CommentsBe the first to comment