iRule to set SameSite for compatible clients and remove it for incompatible clients (LTM|ASM|APM)

Hoolio · ‎10-Feb-2020

A bunch of us have been refining approaches to help customers handle the new browser enforcement of the HTTP cookie SameSite attribute.

I think we have a pretty solid approach now to handle compatible and incompatible user-agents.

The iRule:

Allows the admin to set the SameSite attribute on BIG-IP and web application cookies (all cookies, explicitly named cookies or cookies that start with a string) for user-agents that handle the SameSite attribute
Allows the admin to remove the SameSite attribute for user-agents which do not support SameSite=None. The behavior for an incompatible client receiving a cookie with SameSite not set should be the same as a compatible client handling SameSite=None (the incompatible client should send the cookie on third party requests)

The iRule uses Simon Kowallik's updated string matching logic to handle the incompatible user-agent from Chomium's blog: https://www.chromium.org/updates/same-site/incompatible-clients

Note this iRule only modifies BIG-IP and web application cookies found in Set-Cookie headers. It does not attempt to modify cookies that the BIG-IP or web application sets via Javascript or other methods. BIG-IP ASM is known to set some cookies via Javascript. If you require support for this, please open a case with F5 support (https://support.f5.com) and request your case be added to:

BZ875909: Allow admin configuration of SameSite attribute on ASM system cookies set via Set-Cookie and Javascript

Updates to the iRule can be found in the irules-toolbox repo on GitHub. This specific version is for v12+, but there is a pre-v12 version in the repo as well.

Configuration options in the iRule:

samesite_security: Set this to Strict, Lax or None. The description for these values is in the iRule quoted below:

 # Set BIG-IP and app cookies found in Set-Cookie headers using this iRule to:
 #
 # 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.
 #
 # 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: browser never sends cookies in requests to third party domains
 #
 #   Above definitions from: https://docs.microsoft.com/en-us/microsoftteams/platform/resources/samesite-cookie-update 
 #
 # Note: this iRule does not modify cookies set on the client using Javascript or other methods outside of Set-Cookie headers!
 set samesite_security "none"

Uncomment the next command if you're using this iRule on an APM virtual server with an access profile:

 # Uncomment when using this iRule on an APM-enabled virtual server so the MRHSession cookies will be rewritten
 # The iRule cannot be saved on a virtual server with this option uncommented if there is no Access profile also enabled
 #ACCESS::restrict_irule_events disable

Now define whether you want to rewrite all web application and BIG-IP cookies found in the Set-Cookie header(s). Set this to 1 to rewrite SameSite on all cookies in Set-Cookie headers. Else, if you want to define specifically named or prefixed cookies, set this option to 0, and proceed to the next two config options, #2 and #3

 # 1. If you want to set SameSite on all BIG-IP and web application cookies for compliant user-agents, set this option to 1
 # Else, if you want to use the next two options for rewriting explicit named cookies or cookie prefixes, set this option to 0
 set set_samesite_on_all 0

If you don't want to rewrite all cookies using option #1 above, you can choose to rewrite explicitly named cookies in option #2. Set the exact cookie names in the named_cookie list. Replace MRHSession and LastMRH_Session, which are examples of the cookies APM uses. If you do not want to rewrite exact cookie names, comment out the first example and uncomment the second example "set named_cookies {}"

 # 2. Rewrite SameSite on specific named cookies
 #
 # To enable this, list the specific named cookies in the list command and comment out the second set command below
 # To disable this, set this variable to {} and comment out the first set command below
 set named_cookies [list {MRHSession} {LastMRH_Session}]
 #set named_cookies {}

If you don't want to rewrite all cookies using option #1 above, you can choose to rewrite cookies using a prefix in option #3. Set the cookie name prefixes in the named_cookie list. Replace BIGipServer and TS, which are examples of the cookie prefixes LTM uses for persistence and ASM uses for session tracking, with the prefixes of the cookie names you want to rewrite. If you do not want to rewrite using cookie name prefixes, comment out the first example and uncomment the second example "set named_cookies {}"

 # 3. Rewrite cookies with a prefix like BIG-IP persistence cookies
 # To enable this, list the cookie name prefixes in the list command and comment out the second set command below
 # To disable this, set this variable to {} and comment out the first set command below
 set cookie_prefixes [list {BIGipServer} {TS}]
 #set cookie_prefixes {}

If your application or BIG-IP configuration sets cookies in the Set-Cookie headers with SameSite=None, incompatible user-agents will either reject the cookie or treat the cookie as if it was set for SameSite=Strict (https://www.chromium.org/updates/same-site/incompatible-clients).

You can set remove_samesite_for_incompatible_user_agents to 1 to have this iRule remove SameSite attributes from all cookies sent to incompatible browsers.

 # For incompatible user-agents, this iRule can remove the SameSite attribute from all cookies sent to the client via Set-Cookie headers
 # This is only necessary if BIG-IP or the web application being load balanced sets SameSite=None for all clients
 # set to 1 to enable, 0 to disable
 set remove_samesite_for_incompatible_user_agents 1

While testing, you can set samesite_debug to 1 to test and get debug written to /var/log/ltm. Make sure to disable this option when you're done testing, before putting the iRule into production!

 # Log debug to /var/log/ltm? 1=yes, 0=no
 # set to 0 after testing
 set samesite_debug 1

The full iRule:

(Updates can be found in the irules-toolbox repo on GitHub. This specific version is for v12+, but there is a pre-v12 version in the repo as well.)

# iRule: samesite_cookie_handling
# author: Simon Kowallik
# version: 1.3
#
# History: version - author - description
#	 1.0 - Simon Kowallik - initial version 
#	 1.1 - Aaron Hooley - updated to add support for setting SameSite to Strict|Lax|None for BIG-IP and app cookies in Set-Cookie headers
#											- Add option to remove SameSite=None cookies for incompatible browsers
#	 1.2 - Aaron Hooley - Added option to rewrite all cookies without naming them explicitly or with prefixes
#	 1.3 - Aaron Hooley - set samesite_compatible to 0 by default instead of a null string 
#
# What the iRule does:
# Sets SameSite to Strict, Lax or None (and sets Secure when SameSite=None) for compatible user-agents
# Optionally removes SameSite attribute from all cookies for incompatible user-agents so they'll handle cookies as if they were SameSite=None
#
# The iRule should work for:
# - LTM for web app cookies and persistence cookies, except those that the web app sets via Javascript
# - ASM for web app cookies and all ASM cookies except those that ASM or the web app sets via Javascript
# - APM for web app cookies and all APM cookies you configure in the config variable $named_cookies, except those that the web app sets via Javascript
#
# The iRule requires BIG-IP v12 or greater to use the HTTP::cookie attribute command
#
# RFC "standards"
# https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
# https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-05
# further reading:
# https://web.dev/samesite-cookies-explained/
# https://web.dev/samesite-cookie-recipes/
# https://blog.chromium.org/2019/10/developers-get-ready-for-new.html
# https://www.chromium.org/updates/same-site
# https://www.chromium.org/updates/same-site/incompatible-clients

proc checkSameSiteCompatible {user_agent} {
	# Procedure to check if a user-agent supports SameSite=None on cookies
	#
	# usage: 
	#		set isSameSiteCompatible [call checkSameSiteCompatible {User-Agent-String}]
	#
	# check for incompatible user-agents: https://www.chromium.org/updates/same-site/incompatible-clients
	# based on https://devcentral.f5.com/s/articles/HTTP-cookie-SameSite-test-detection-of-browsers-with-incompatible-SameSite-None-handling
	switch -glob -- [set user_agent [string tolower $user_agent]] {
		{*chrome/5[1-9].[0-9]*} -
		{*chrome/6[0-6].[0-9]*} -
		{*chromium/5[1-9].[0-9]*} -
		{*chromium/6[0-6].[0-9]*} -
		{*ip?*; cpu *os 12*applewebkit*} -
		{*macintosh;*mac os x 10_14*version*safari*} -
		{mozilla*macintosh;*mac os x 10_14*applewebkit*khtml, like gecko*} {
			# no samesite support
			return 0
		}
		{*ucbrowser/*} {
			switch -glob -- $user_agent {
				{*ucbrowser/[1-9].*} -
				{*ucbrowser/1[0-1].*} -
				{*ucbrowser/12.[0-9].*} -
				{*ucbrowser/12.1[0-1].*} -
				{*ucbrowser/12.12.*} -
				{*ucbrowser/12.13.[0-2]*} {
					# no samesite support
					return 0
				}
			}
		}
	}
	# If the current user-agent didn't match any known incompatible browser list, assume it can handle SameSite=None 
	return 1

	# CPU Cycles on Executing (>100k test runs)
	#	 Average								 22000-42000 (fastest to slowest path)
	#	 Maximum								214263
	#	 Minimum								 13763
}

# the iRule code
when CLIENT_ACCEPTED priority 100 {

	# Set BIG-IP and app cookies found in Set-Cookie headers using this iRule to:
	#
	# 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.
	#
	# 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: browser never sends cookies in requests to third party domains
	#
	#		Above definitions from: https://docs.microsoft.com/en-us/microsoftteams/platform/resources/samesite-cookie-update 
	#
	# Note: this iRule does not modify cookies set on the client using Javascript or other methods outside of Set-Cookie headers!
	set samesite_security "none"

	# Uncomment when using this iRule on an APM-enabled virtual server so the MRHSession cookies will be rewritten
	# The iRule cannot be saved on a virtual server with this option uncommented if there is no Access profile also enabled
	#ACCESS::restrict_irule_events disable

	# 1. If you want to set SameSite on all BIG-IP and web application cookies for compliant user-agents, set this option to 1
	# Else, if you want to use the next two options for rewriting explicit named cookies or cookie prefixes, set this option to 0
	set set_samesite_on_all 0

	# 2. Rewrite SameSite on specific named cookies
	#
	# To enable this, list the specific named cookies in the list command and comment out the second set command below
	# To disable this, set this variable to {} and comment out the first set command below
	set named_cookies [list {MRHSession} {LastMRH_Session}]
	#set named_cookies {}

	# 3. Rewrite cookies with a prefix like BIG-IP persistence cookies
	# To enable this, list the cookie name prefixes in the list command and comment out the second set command below
	# To disable this, set this variable to {} and comment out the first set command below
	set cookie_prefixes [list {BIGipServer} {TS}]
	#set cookie_prefixes {}

	# For incompatible user-agents, this iRule can remove the SameSite attribute from all cookies sent to the client via Set-Cookie headers
	# This is only necessary if BIG-IP or the web application being load balanced sets SameSite=None for all clients
	# set to 1 to enable, 0 to disable
	set remove_samesite_for_incompatible_user_agents 1

	# Log debug to /var/log/ltm? 1=yes, 0=no
	# set to 0 after testing
	set samesite_debug 1

	# You shouldn't have to make changes to configuration below here

	# Track the user-agent and whether it supports the SameSite cookie attribute
	set samesite_compatible 0
	set user_agent {}

	if { $samesite_debug }{
		set prefix "[IP::client_addr]:[TCP::client_port]:"
		log local0. "$prefix [string repeat "=" 40]"
		log local0. "$prefix \$samesite_security=$samesite_security; \$set_samesite_on_all=$set_samesite_on_all; \$named_cookies=$named_cookies; \$cookie_prefixes=$cookie_prefixes, \
			\$remove_samesite_for_incompatible_user_agents=$remove_samesite_for_incompatible_user_agents"
	}
}

# Run this test event before any other iRule HTTP_REQUEST events to set the User-Agent header value
# Comment out this event when done testing user-agents
#when HTTP_REQUEST priority 2 {

	# known compatible 
#	HTTP::header replace user-agent {my compatible user agent string}
	# known INcompatible 
#	HTTP::header replace user-agent {chrome/51.10}
#}

# Run this iRule before any other iRule HTTP_REQUEST events
when HTTP_REQUEST priority 100 {

	# If we're setting samesite=none, we need to check the user-agent to see if it's compatible
	if { not [string equal -nocase $samesite_security "none"] }{

		# Not setting SameSite=None, so exit this event
		return
	}

	# Inspect user-agent once per TCP session for higher performance if the user-agent hasn't changed
	if { $samesite_compatible == 0 or $user_agent ne [HTTP::header value {User-Agent}]} {
		set user_agent [HTTP::header value {User-Agent}]
		set samesite_compatible [call checkSameSiteCompatible $user_agent]
		if { $samesite_debug }{
			log local0. "$prefix Got \$samesite_compatible=$samesite_compatible and saved current \$user_agent: $user_agent"
		}
	}
}
# Run this response event with priority 900 after all other iRules to parse the final cookies from the application and BIG-IP
when HTTP_RESPONSE_RELEASE priority 900 {

	# Log the pre-existing Set-Cookie header values
	if { $samesite_debug }{ log local0. "$prefix Set-Cookie value(s): [HTTP::header values {Set-Cookie}]" }

	if { $samesite_compatible } {
		# user-agent is compatible with SameSite=None, set SameSite on matching cookies

		if { $set_samesite_on_all }{
			if { $samesite_debug }{ log local0. "$prefix Setting SameSite=$samesite_security on all cookies and exiting" }
			foreach cookie [HTTP::cookie names] {

				if { $samesite_debug }{ log local0. "$prefix Set SameSite=$samesite_security on $cookie" }

				# Remove any prior instances of SameSite attributes
				HTTP::cookie attribute $cookie remove {samesite} 

				# Insert a new SameSite attribute
				HTTP::cookie attribute $cookie insert {samesite} $samesite_security

				# If samesite attribute is set to None, then the Secure flag must be set for browsers to accept the cookie
				if {[string equal -nocase $samesite_security "none"]} {
					HTTP::cookie secure $cookie enable
				}
			}
			# Exit this event in this iRule as we've already rewritten all cookies with SameSite
			return
		}
		# Match named cookies exactly
		if { $named_cookies ne {} }{
			foreach cookie $named_cookies {
				if { [HTTP::cookie exists $cookie] } {
					# Remove any pre-existing SameSite attributes from this cookie as most clients use the most strict value if multiple instances are set
					HTTP::cookie attribute $cookie remove {SameSite}

					# Insert the SameSite attribute
					HTTP::cookie attribute $cookie insert {SameSite} $samesite_security

					# If samesite attribute is set to None, then the Secure flag must be set for browsers to accept the cookie
					if {[string equal -nocase $samesite_security "none"]} {
						HTTP::cookie secure $cookie enable
					}
				if { $samesite_debug }{ log local0. "$prefix Matched explicitly named cookie $cookie, set SameSite=$samesite_security" }
				if { $samesite_debug }{ log local0. "$prefix " }
				}
			}
		}
		# Match a cookie prefix (cookie name starts with a prefix from the $cookie_prefixes list)
		if { $cookie_prefixes ne {} }{
			foreach cookie [HTTP::cookie names] {
				foreach cookie_prefix $cookie_prefixes {
					if { $cookie starts_with $cookie_prefix } {
						# Remove any pre-existing SameSite attributes from this cookie as most clients use the most strict value if multiple instances are set
						HTTP::cookie attribute $cookie remove {SameSite}

						# Insert the SameSite attribute
						HTTP::cookie attribute $cookie insert {SameSite} $samesite_security

						# If samesite attribute is set to None, then the Secure flag must be set for browsers to accept the cookie
						if { [string equal -nocase $samesite_security "none"] } {
							HTTP::cookie secure $cookie enable
						}
						if { $samesite_debug }{ log local0. "$prefix Matched prefixed cookie $cookie, with prefix $cookie_prefix, set SameSite=$samesite_security, breaking from loop" }
						break
					}
				}
			}
		}
	} else {

		# User-agent can't handle SameSite=None

		if { $remove_samesite_for_incompatible_user_agents }{

			# User-agent can't handle SameSite=None, so remove SameSite attribute from all cookies if SameSite=None
			# This will use CPU cycles on BIG-IP so only enable it if you know BIG-IP or the web application is setting 
			# SameSite=None for all clients including incompatible ones
			foreach cookie [HTTP::cookie names] {
				if { [string tolower [HTTP::cookie attribute $cookie value SameSite]] eq "none" }{
					HTTP::cookie attribute $cookie remove SameSite
					if { $samesite_debug }{ log local0. "$prefix Removing SameSite for incompatible client from cookie=$cookie" }
				}
			}
		}
	}
	# Log the modified Set-Cookie header values
	if { $samesite_debug }{ log local0. "$prefix Final Set-Cookies: [HTTP::header values {Set-Cookie}]" }
}

David_Scott · ‎16-Feb-2020

if you're on a version that doesn't support the HTTP::cookie attribute method (v11 mainly) here's a way to add the attribute it. Ideally you'd upgrade to v12+ but if that's not an option it does add the attribute. Obviously change SameSitee=none to

when HTTP_RESPONSE {
	set COOKIE_VAL [HTTP::header values "Set-Cookie"]
	HTTP::header remove "Set-Cookie"
 
	foreach COOKIE_NAME $COOKIE_VAL {
		HTTP::header insert "Set-Cookie" "${COOKIE_NAME}; SameSite=none"
                HTTP::cookie secure ${COOKIE_NAME} enable
	}
}

the above and this could probably be integrated together for older versions until they can upgrade.

Simon_Kowallik · ‎16-Feb-2020

Hi! Just don't forget to set Secure attribute with SameSite=None as well, otherwise it will have no effect.

See: https://tools.ietf.org/html/draft-west-cookie-incrementalism-00#section-4.2

David_Scott · ‎16-Feb-2020

good catch, I initially had the cookie secure in there and accidently removed it when I was removing the log lines before posting. Added it back in

Funkdaddy · ‎24-Feb-2020

Regarding "Incompatible Clients" - our assumption is that incompatible clients simply ignore the SameSite flag - isn't this the case in general? If so, then why go through the trouble of removing it?

Simon_Kowallik · ‎24-Feb-2020

Unfortunately the behaviour isn't consistent across incompatible clients. SameSite=None wasn't introduced in the first drafts of the RFC, which might be the reason why there is inconsistent behaviour, which ranges from treating SameSite=None as SameSite=strict to ignoring the cookie.

Here is the list of incompatible user-agents according to google chromium:

https://www.chromium.org/updates/same-site/incompatible-clients

Here is a quick read on this topic:

https://www.linkedin.com/pulse/samesite-cookies-your-legacy-web-apps-simon-kowallik

Funkdaddy · ‎25-Feb-2020

Thanks Simon that was helpful information.

lorenze · ‎09-Jul-2020

I tried creating an irule with just the following entry but seems it doesn't fix the samesite concern:

when HTTP_RESPONSE {
	set COOKIE_VAL [HTTP::header values "Set-Cookie"]
	HTTP::header remove "Set-Cookie"
 
	foreach COOKIE_NAME $COOKIE_VAL {
		HTTP::header insert "Set-Cookie" "${COOKIE_NAME}; SameSite=none"
                HTTP::cookie secure ${COOKIE_NAME} enable
	}
}

when HTTP_RESPONSE {
 
        HTTP::header replace Set-Cookie "[HTTP::header Set-Cookie]; HttpOnly;SameSite=none; Secure"
 
 
 
  }

Is there something I am missing?

Thanks!

MarkDemich · ‎24-Sep-2020

In our situation we are only interested in fixing the BigIP cookie for sticky load balancing. If that's the case wouldn't it make more sense delay the call to checkSameSiteCompatible until we are processing the response. In that way we can avoid doing all the regex compares, if there are no cookies present in the response that we want to change. It seems wasteful for me to be processing all those regexes for each request when there are not relevant cookies.

If that's the case, even with all these options to set all cookies etc, I think there should be a way to store off the user agent value in a variable when processing the request, then use it in the response while maintaining a flag that will tell you if you already checked. For instance we can initialize same_site_compatible to -1 which tells us it has not yet been checked. This way we can arrange the logic during the response processing to only check the user agent once for the first occurence of a cookie we want to process.

I'm not proficient in writing IRules so maybe I'm missing something important here, so I would appreciate feedback letting me know if my idea has flaws besides the obvious one of adding some more complexity to the logic.

Thanks,

Mark

vaahtera · ‎10-Nov-2020

This iRule seems not to be compatible with 15.1.1 build 0.0.6 as it gives this error to LTM logs:

TCL error: /Common/Add_SameSite_cookie_v2 <HTTP_RESPONSE_RELEASE> - Can't call after responding - ERR_NOT_SUPPORTED (line 1) invoked from within "HTTP::cookie names"

Any ideas on how to fix this?

Nicotrel · ‎04-Jan-2021

Any update to this? We are facing same issue with 15.1.2.

LiefZimmerman · ‎04-Jan-2021

deferring to - Have you seen the comments on this?

Hoolio · ‎04-Jan-2021

Hi and ,

Do you have APM enabled on the virtual server? Or another iRule that is sending an HTTP response?

I believe the issue is described in K23237429:

K23237429: TCL error: ERR_NOT_SUPPORTED after upgrade to version 14.1.0 or later

https://support.f5.com/csp/article/K23237429

Once I understand the configuration that's causing the TCL error, I can try to suggest a fix for it.

Thanks, Aaron

vaahtera · ‎04-Jan-2021

We have APM enabled on this affected virtual server and also another iRule. The reason we were using the SameSite iRule is that in this case we are using external IdP and when the SAML response in SLO comes back, we need to modify the APM cookie SameSite values to None in order it to work. I combined the two iRules together but never got it to work and always got the same error i posted here earlier. The workaround we came up was to do a redirect after the SAML SLO response and removed that SameSite iRule code lines from the virtual server. The workaround is not ideal, but at least we got it working again. I think I have read somewhere that the APM SameSite values are modifiable from APM profile in 16.x version but we are not yet ready to upgrade to that release.

Nicotrel · ‎05-Jan-2021

Good day,

Yes APM is enabled on the virtual server. We have another iRule that uses HTTP response. This was added (2/3 years ago) to fix issues opening links to this site from MS Office documents. I have removed this iRule and am still receiving the same TCL error.

when HTTP_REQUEST {
  HTTP::header insert x-sap-webdisp-ap "HTTPS=443"
  switch -glob -- [string tolower [HTTP::header "User-Agent"]] {
    "*word*" -
    "*excel*" -
    "*office upload*" -
    "*office existence discovery*" -
    "*office protocol discovery*" -
    "*soap toolkit*" -
    "*ms-office*" -
    "*microsoft office onenote*" -
    "*webdav-miniredir*" -
    "*frontpage*" -
    "*msfrontpage*" - "*shareplus*" { HTTP::respond 200 } }
}

Example Errors:

Jan  4 08:45:54 <HOSTNAME> err tmm3[22340]: 01220001:3: TCL error: /Common/<IRULE_NAME> <HTTP_RESPONSE_RELEASE> - Can't call after responding - ERR_NOT_SUPPORTED (line 1)     invoked from within "HTTP::cookie exists $cookie"     ("foreach" body line 2)     invoked from within "foreach cookie $named_cookies {                  if { [HTTP::cookie exists $cookie] } {                                   # Remove any pre-existing SameSite attributes from this cookie as most..."
Jan  4 08:45:54 <HOSTNAME> err tmm3[22340]: 01220001:3: TCL error: <IRULE_NAME> <HTTP_RESPONSE_RELEASE> - Can't call after responding - ERR_NOT_SUPPORTED (line 29)     invoked from within "HTTP::cookie exists $cookie"     ("foreach" body line 2)     invoked from within "foreach cookie $named_cookies {                 if { [HTTP::cookie exists $cookie] } {                                   # Remove any pre-existing SameSite attributes from this cookie as most..."

Thanks,

Jason

Hoolio · ‎05-Jan-2021

Thanks for your replies and . Could you add this line to the samesite iRule just after the HTTP_RESPONSE_RELEASE line?

Look for this line (line 188 in https://github.com/f5devcentral/irules-toolbox/blob/master/security/http/cookies/samesite-attributes...😞

# Run this response event with priority 900 after all other iRules to parse the final cookies from the application and BIG-IP
when HTTP_RESPONSE_RELEASE priority 900 {

And add this return command after it, as listed below:

# Exit this event if another iRule has already sent an HTTP response (F5 article K23237429)
if {[HTTP::has_responded]}{return}

Please test this on a separate non-production virtual server or during a maintenance window in case there are any issues.

Thanks, Aaron

Nicotrel · ‎05-Jan-2021

Initial testing looks good for me. Unfortunately the setup I can test on is slightly different than production so I cannot confirm it completely resolves my issue.

Thanks,

Jason

Juan_Cuevas · ‎01-Mar-2021

Hello, having a Policy with redirection to another URL, the SameSite irule does not work and sends Reset, we had to separate these redirects in another irule to solve it.

Who knows why this behavior?

Thanks

Hoolio · ‎01-Mar-2021

Hi Juan,

Are you using the latest version of the iRule which includes these lines?

https://github.com/f5devcentral/irules-toolbox/blob/master/security/http/cookies/samesite-attributes.tcl

# 1.5 - Aaron Hooley - Fixed issue noted in https://support.f5.com/csp/article/K23237429 by disabling the iRule if another response has already been sent

# Run this response event with priority 900 after all other iRules to parse the final cookies from the application and BIG-IP
when HTTP_RESPONSE_RELEASE priority 900 {
 
	# Don't do anything if a response has already been triggered for this request
	if {[HTTP::has_responded]}{
		if { $samesite_debug }{ log local0. "$prefix Exiting as response has already been triggered by another configuration option" }
		# exit this event in this iRule
		return
	}

Aaron

axelfelix · ‎05-Aug-2021

Hello ,

Nice Irule and work but I get an issue with it, I have a F5 with version BIG-IP 13.1.3.2 Build 0.0.4 Point Release 2.

I get the error below:

01070151:3: Rule [/Common/SameSite] error: /Common/SameSite:192: error: [undefined procedure: HTTP::has_responded][HTTP::has_responded]

So regarding the documentation, the 'HTTP::has_responded' variable appears after version BIGIP-14.0.

Then I've checked the GitHub repo dedicated to prior version 12 (https://github.com/f5devcentral/irules-toolbox/blob/master/security/http/cookies/samesite-attributes...) and I can see the the condition below is not taken into consideration:

when HTTP_RESPONSE_RELEASE priority 900 {
 
	# Don't do anything if a response has already been triggered for this request
	if {[HTTP::has_responded]}{
		if { $samesite_debug }{ log local0. "$prefix Exiting as response has already been triggered by another configuration option" }
		# exit this event in this iRule
		return
	}

So I have decided to test the Irule (https://github.com/f5devcentral/irules-toolbox/blob/master/security/http/cookies/samesite-attributes...) removing the part below:

# Don't do anything if a response has already been triggered for this request
if {[HTTP::has_responded]}{
	if { $samesite_debug }{ log local0. "$prefix Exiting as response has already been triggered by another configuration option" }
	# exit this event in this iRule
	return
}

It seems to work correctly, but could you confirm if doing that we can get side effects or not, what could be the exact impact ?

Do you have any advice to replace it otherwise by another method ?

Many thanks in advance.

Have a nice day,

Alex

Simon_Kowallik · ‎06-Aug-2021

Hi ,

TMOS version 13.x doesn't support `HTTP::has_responded`, this command was introduced in TMOS version 14.1.

The below support article has detailed information about the background.

K23237429: TCL error: ERR_NOT_SUPPORTED after upgrade to version 14.1.0 or later

If this is the only iRule attached to the virtual server and you don't use LTM policies there is nothing to worry about. If you do, just check if any of the criteria applies to you and re-arrange the iRule code accordingly to be prepared for a later TMOS upgrade.

Regards

Simon

Per_Hagstrom · ‎16-Jan-2022

FYI, Firefox just released SameSite cookie control in v96.0 (Jan 11, 2022), and it broke login to Outlook (2016) Web Access for us. Have been using your iRule for Chrome, so just added this agent line, and now we are all good again:

{*firefox/9[0-9].[0-9]*} -

That should cover any Firefox version from v90.0 - v99.9.

Hope that might help someone else.

/ Per

DevCentral

iRule to set SameSite for compatible clients and remove it for incompatible clients (LTM|ASM|APM)

Updates to the iRule can be found in the irules-toolbox repo on GitHub. This specific version is for v12+, but there is a pre-v12 version in the repo as well.

Configuration options in the iRule:

The full iRule: