Forum Discussion

Dave_Burnett_20's avatar
Dave_Burnett_20
Icon for Nimbostratus rankNimbostratus
Nov 10, 2008

Modified Domain Cookie blocking

We have recently installed a pair of F56400s (v9.4.3) in front of our website with ASM in blocking mode.

 

 

Despite the fact that our Website only utilises a handful of cookies (all configured within the ASM) we are seeing and blocking loads of Modified Domain Cookie violations.

 

 

It would appear that when users are visitng our website their browsers are trying to present cookies that are nothing to do with our domain whatsoever which the F5 is blocking because it, quite rightly, does not recognise the cookie as being from the application. This action, however, is blocking the users from our site

 

 

Modified Cookie Violation is another standard ASM policy feature which we have not altered so, to my way of thinking, anyone with an F5 will be experiencing the same kind of problem.

 

 

Does anyone have the same issue? Does anyone know why we are seeing this behaviour i.e. browsers trying to give us cookies we don't want.

 

 

Any feedback/advice would be gratefully received
  • hi Aaron, i got same situation for this BCSI-* blocking. Did your script above has been tested and apply in production environment? how was the result? thx
  • Hi,

     

     

    I've been using a script very like the one Aaron suggested here in production for some time now. As well as the BCSI cookies, it also strips cookies beginning with TS, as I was having a similar problem with those.

     

    It works fine for me.
  • alfian, the iRule should work fine. Though if you're on 9.4.2 or higher, you can configure a wildcard of BCSI-* in the allowed modified domain cookie setting.

     

     

    Allyn, the TS cookies are what ASM uses to track the web app's cookies and other dynamic settings. You should ideally leave the TS cookies as they're used by ASM for validation. If you don't want to track any cookies, you can just disable the modified domain cookie violation in the blocking mask of the policy.

     

     

    Aaron
  • That looks like it should work. You could add logging to see what's happening. If it's a production virtual server, try adding the logging just for your client IP.

    You could combine the two iRules so you only loop through the cookies once:

    
    when CLIENT_ACCEPTED {
    
        Check if the client is our test IP
       if {[IP::addr [IP::client_addr] equals 1.2.3.4]}{
          if {$debug}{log local0. "Debug enabled for [IP::client_addr]"}
          set debug 1
       } else {
          set debug 0
       }
    }
    when HTTP_REQUEST {
    
       if {$debug}{log local0. "\[HTTP::cookie names\]: [HTTP::cookie names]"}
    
        Loop through each cookie by name
       foreach acookie [HTTP::cookie names] {
    
           Check if cookie starts with bcsi or _em_
          if {[string match -nocase "bcsi-*" $acookie] or [string match -nocase "_em_*" $acookie]}{
    
             if {$debug}{log local0. "Removing cookie $cookie: [HTTP::cookie value $cookie]"}
    
              Remove cookie
             HTTP::cookie remove $acookie
          }
       }
    }
    

    Aaron
  • Aron

     

     

    how about the combine script if i want to remove the logging? Thx
  • Hi Alfian,

     

     

    You can either set debug to 0 or comment out/remove the lines which start with "if {$debug}{log local0. "

     

     

    Aaron
  • Aaron,

     

     

    is this script ok?

     

     

    when HTTP_REQUEST {

     

     

    Loop through each cookie by name

     

    foreach acookie [HTTP::cookie names] {

     

     

    Check if cookie starts with bcsi or _em_

     

    if {[string match -nocase "bcsi-*" $acookie] or [string match -nocase "_em_*" $acookie]}{

     

     

    Remove cookie

     

    HTTP::cookie remove $acookie

     

    }

     

    }

     

    }