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

Mark_22062's avatar
Mark_22062
Icon for Nimbostratus rankNimbostratus
Nov 12, 2014

ASM Custom Response Page

Hi there,

I am using a custom response page for ASM, as part of that I want to clear some troublesome persistent cookies that are triggering alerts.

I've got the following setup in the response and it seems to work correctly for a test VIP, but on the production side I can see the headers in the response but it doesn't actually clear the cookies.

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Set-Cookie: ___utmvc=deleted; domain=.foo.bar; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: testcookie=deleted; domain=.foo.bar; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT
Connection: close

I also tried using an iRule to do the same using the ASM_REQUEST_BLOCKING event but that doesn't trigger at all.

Any ideas?

ASM Advanced WAF
security

2 Replies

  • Thomas_Schocka1's avatar
    Thomas_Schocka1
    Icon for Altocumulus rankAltocumulus
    Nov 13, 2014

    Hi Mark,

    I believe you could use an iRule to do it, by first setting a variable that indicates that it needs to 'unset cookies', and then inserting the cookies in the HTTP_RESPONSE_RELEASE event. I'm not sure in which ASM event you'd be setting the 'need_to_unset_cookies' variable to 1, but once you found it, try something like this:

    when HTTP_RESPONSE_RELEASE {
    if { $need_to_unset_cookies == 1 } {
         List the cookies
        set cookies [HTTP::header values "Set-Cookie"]
         Remove existing Set-Cookie headers
        HTTP::header remove "Set-Cookie"
         Run through the list, reinserting only those you want
        foreach cookie $cookies {
            if { !($cookie contains "___utmvc") } {
                HTTP::header insert "Set-Cookie" $cookie
        }
        }
         Insert your custom version of the cookies you wanted to change
        HTTP::header insert "Set-Cookie" "___utmvc=deleted; domain=.foo.bar; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT"
    }
}
  • Mark_van_D's avatar
    Mark_van_D
    Icon for Cirrostratus rankCirrostratus
    Nov 13, 2014

    With the iRule this time.

    Ended up modifying the example ASM_REQUEST_BLOCKING in the wiki to delete the rogue cookie.

    when ASM_REQUEST_BLOCKING
{
  set x [ASM::violation_data]
    for {set i 0} { $i < 7 } {incr i} {
      switch $i {
        0         { log local0. "violation=[lindex $x $i]" }
        1         { log local0. "support_id=[lindex $x $i]" }
        2         { log local0. "web_application=[lindex $x $i]" }
        3         { log local0. "severity=[lindex $x $i]" }
        4         { log local0. "source_ip=[lindex $x $i]" }
        5         { log local0. "attack_type=[lindex $x $i]" }
        6         { log local0. "request_status=[lindex $x $i]" }
        }}

        if {([lindex $x 0] contains "VIOLATION_ATTACK_SIGNATURE_DETECTED")}
 {
   log local0. "VIOLATION_ATTACK_SIGNATURE_DETECTED detected, let's customise the reject page"
   HTTP::cookie remove ___utmvc
   HTTP::header remove Content-Length
   HTTP::header insert "Set-Cookie" "___utmvc=deleted; domain=.foo.bar; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT"

     set response "Apology PageWe are sorry,\
 but there was a problem processing your request, please try again."

 ASM::payload replace 0 [ASM::payload length] ""
 ASM::payload replace 0 0 $response
 }
 }

    I just hashed out the logging but it came in handy in determining the violation.