Add SameSite attribute to APM Cookies

Problem this snippet solves:

This irule add SameSite attribute with value None to APM Cookies. related to Chrome 80 behavior change : Cookies default to SameSite=Lax


When you put "SameSite=None", you must have the "Secure" attribute set to the cookie.

How to use this snippet:

Add the irule to a Virtual Server.


Change value of the attribute from None to desired value.


Pay attention to possible interferences with other irules applied to Virtual Servers.

Code :

when RULE_INIT {
    set static::apm_cookies { "F5_fullWT" "F5_HT_shrinked" "F5_ST" "LastMRH_Session" "MRHSequence" "MRHSession" "MRHSHint" "TIN" "F5_VdiUserClientChoicecitrix" "F5_VdiUserClientChoicevmware_view" }
}

when CLIENT_ACCEPTED {
    ACCESS::restrict_irule_events disable
}

when HTTP_RESPONSE_RELEASE {
    
    foreach apm_cookie ${static::apm_cookies} {
        if { [HTTP::cookie exists ${apm_cookie}] } {
            HTTP::cookie attribute ${apm_cookie} insert "SameSite" None 
		if  { ![HTTP::cookie attribute ${apm_cookie} exists "secure"] } {
			HTTP::cookie attribute ${apm_cookie} insert "Secure"
		}
        }
    }
}

Tested this on version:

12.1
Published Jan 30, 2020
Version 1.0
application delivery
BIG-IP Access Policy Manager (APM)
iRules
security
  • Lucas_Thompson's avatar
    Lucas_Thompson
    Icon for Employee rankEmployee
    Jan 31, 2020

    Thanks Yann! We've been testing with this more conservative iRule. I think this may work for some (most?) LTM+APM use cases and should execute less code less often. However, as you know APM is deployed in a lot of different ways and it's going to be hard to know for sure what the impacts are before we get bigger user populations on Chrome 80.

     

    Any feedback is welcome.

     

    edit: changed "Lax" to "None".

    It's been brought up that this issue will also impact LTM persistence cookies, which have a much bigger use case.

     

    when CLIENT_ACCEPTED {
  # This allows events to fire when APM is doing policy operations
  ACCESS::restrict_irule_events disable
}
 
when HTTP_RESPONSE_RELEASE {
  # APM cookies are set only in 302s
  if { [HTTP::status] == "302" } {
    # Make sure we have a mrhsession cookie here
    if { [HTTP::cookie exists "MRHSession"] } {
      HTTP::cookie attribute "MRHSession" insert "SameSite" "None"
    } else {
      #log local0. "No MRHSession Found"
    }
  }
}

     

  • Yann_Desmarest's avatar
    Yann_Desmarest
    Icon for Cirrus rankCirrus
    Feb 03, 2020

    Hi Lucas,

     

    You have several other Cookies sent by APM. The most important one is LastMRH_Session.

     

    If you don't specify any SameSite attribute, Chrome will define "Lax" as default behavior. "Lax" means that GET requests to same hostname and domains are allowed. When you are using SAML, OAuth, OIDC, or Multidomain SSO, you will have POST requests. Those POST requests are not allowed by default thus breaking the authentication flow. It concerns mainly embedded contents and cross origin requests.

     

    Regards

     

    Yann

  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Feb 03, 2020

    This Microsoft page has a simpler explanation for the SameSite attribute values than the RFC:

     

    https://docs.microsoft.com/en-us/microsoftteams/platform/resources/samesite-cookie-update

     

    Lax Cookies will be sent automatically only in a first-party context and with HTTP GET requests. SameSite cookies will be withheld on cross-site sub-requests, such as calls to load images or iframes, but will be sent when a user navigates to the URL from an external site, e.g., by following a link.

     

    Strict The browser will only send cookies for first-party context requests (requests originating from the site that set the cookie). If the request originated from a different URL than that of the current location, none of the cookies tagged with the Strict attribute will be sent.

     

    None Cookies will be sent in both first-party context and cross-origin requests; however, the value must be explicitly set to None and all browser requests must follow the HTTPS protocol and include the Secure attribute which requires an encrypted connection. Cookies that don't adhere to that requirement will be rejected. Both attributes are required together. If just None is specified without Secure or if the HTTPS protocol is not used, the third-party cookie will be rejected.

  • Hoolio's avatar
    Hoolio
    Ret. Employee
    Feb 11, 2020

    I think this latest iRule handles more scenarios for SameSite including user-agents that don't support cookies with SameSite=None.

     

    https://devcentral.f5.com/s/articles/iRule-to-set-SameSite-for-compatible-clients-and-remove-it-for-incompatible-clients-LTM-ASM-APM