HTTP cookies have become an essential part of any web application, but they’re often vulnerable to attacks such as cross-site request forgery and cross-site scripting, which can lead to the theft of sensitive user data. Cookie hardening is a first step toward making online activity more secure, and the ‘SameSite’ cookie attribute can help you implement a secure-by-default model for your cookies.

In this blog post, we’ll look at how to place the ‘SameSite’ cookie attribute, in both a same-site and cross-site context, into cookies inserted by applications front-ended by Citrix ADC. You can learn more about the ‘SameSite’ cookie attribute here.

Protecting Cookies Against CSRF Vulnerabilities

Cross-site request forgery (CSRF) is an HTTP vulnerability attackers can use to hijack a user account and take control of web transactions. The ‘SameSite’ cookie attribute helps to protect apps against CSRF attacks by restricting cookie usage in a same-site context.

Web apps generally use HTTP cookies to authenticate users and track user activities. If your HTTP-based apps use cookies and are never accessed in a cross-site context, it’s critical to protect the cookies against cross-site misuse. If Citrix ADC front-ends your application, you don’t need to make changes to the back end. Instead, you can append the ‘SameSite=strict’ cookie attribute to back-end cookies using these rewrite policies.

add rewrite action append_samesite_cookie_action replace_all http.RES.full_Header “\”SameSite=strict; path=/\”” -search “regex(re!(?i)(path=\\/)!)”
add rewrite policy append_samesite_cookie “http.RES.HEADER(\”Set-Cookie\”).EXISTS” append_samesite_cookie_action​
bind lb vserver <LB vserver name > -policyName append_samesite_cookie -priority 20 -gotoPriorityExpression next -type RESPONSE

To protect back-end apps from cross-site scripting (XSS) attacks and the use of cookies in non-secure HTTP communications, add the ‘secure’ and ‘httponly’ attributes to secure your cookies (in addition to the above cookie attributes). You can append the ‘secure’ and ‘httponly’ cookie attributes to all the cookies the back-end server returns by binding the below rewrite policy to the load balancing virtual server that front-ends your app.

add rewrite action append_httponly_secure_action replace_all http.RES.full_Header “\”SameSite=strict; secure; httponly; path=/\”” -search “regex(re!(?i)(path=\\/)!)”
add rewrite policy append_httponly_secure_policy “http.RES.HEADER(\”Set-Cookie\”).EXISTS” append_httponly_secure_action
bind lb vserver <LB vserver name > -policyName append_httponly_secure_policy -priority 20 -gotoPriorityExpression next -type RESPONSE

If all apps front-ended by a Citrix ADC have the same requirement to secure their cookies, you can bind the above rewrite policies to the global http response override bind point. This enables you to avoid making the above changes for each of the application-specific LB vservers.

bind rewrite global append_samesite_cookie 20 NEXT -type RES_OVERRIDE

Enable Cross-Site Access Securely

With the Chrome 80 update, cookies with no explicit samesite attribute are treated as ‘SameSite=Lax’. Cookies with ‘SameSite=None; secure’ are available only for cross-site access. Before this update, cookies with no explicit ‘SameSite’ attribute were treated as ‘SameSite=None’, which enabled cross-site access access by default. This requires a change to all apps accessed in a cross-site context.

There are genuine use cases for cross-site access of web apps. To enable cross-site access for apps without making configuration or code changes, you can use the rewrite policy below to append the ‘SameSite=None’ cookie attribute to all the cookies presented by apps.

add rewrite action enable_cross_site_access replace_all http.RES.full_Header “\”SameSite=None; secure; path=/\”” -search “regex(re!(?i)(path=\\/)!)”
add rewrite policy append_samesite_cookie “http.RES.HEADER(\”Set-Cookie\”).EXISTS” enable_cross_site_access ​
bind lb vserver <LB vserver name > -policyName append_samesite_cookie -priority 20 -gotoPriorityExpression next -type RESPONSE

Please note, with the latest Chrome update, cookies with a SameSite attribute set to ‘None’ without the secure attribute are rejected.

If all apps front-ended by Citrix ADC have the same requirement to secure their cookies, you can bind the above rewrite policies to the global http response override bind point instead of individual LB vservers.

bind rewrite global append_samesite_cookie 20 NEXT -type RES_OVERRIDE

Supporting Older Browser Verions for Cross-Site Access

There are browser versions that don’t treat ‘SameSite=None’ in the intended way. For example, they might reject cookies with samesite attribute set to ‘None’. Consider apps that are maintaining user information in cookies. Because the cookie returned by the app is rejected, user information isn’t sent to the app as part of subsequent requests from the user. The result? Each request is treated as a new user session, which can hamper the overall user experience and can have business impact. You can’t append ‘SameSite=None’ to all the responses being served by the application endpoints.

We need to make exceptions to certain browser and OS versions, composing an exception list of browser versions. If the incoming http request is from one of the browser versions in the exception list, skip rewriting the Set-Cookie header. You can achieve this by inspecting the ‘User-Agent’ header in the HTTP request and extracting the browser and OS versions. The rewrite policy below creates a exception list of Chrome browser versions for which appending samesite cookie attribute should be skipped.

add policy expression exp_chrome “(HTTP.REQ.HEADER(\”User-Agent\”).CONTAINS(\”Chrom\”) && HTTP.REQ.HEADER(\”User-Agent\”).REGEX_SELECT(re/Chrom.*\\d+./).REGEX_SELECT(re/\\d+/).TYPECAST_NUM_T(DECIMAL).BETWEEN(51,66))”
add rewrite policy exception_list “exp_chrome” NOREWRITE

You can add other incompatible browser versions to the above exception list as shown below.

add rewrite policy exception_list “exp_chrome || exp_incomp_browser” NOREWRITE
bind lb vserver <vserver name> -policyName exception_list -priority 10 -gotoPriorityExpression end -type RESPONSE
bind lb vserver <vserver name> -policyName append_samesite_cookie -priority 20 -gotoPriorityExpression next -type RESPONSE

If all applications front-ended by Citrix ADC have the same requirement to secure their cookies, you can bind the above rewrite policies to global http response override bind point. This would avoid making the above changes for each of the application specific LB vserver.

bind rewrite global exception_list 10 END -type RES_OVERRIDE
bind rewrite global append_samesite_cookie 20 NEXT -type RES_OVERRIDE

Please note, when binding the policies to either a LB vserver or a global override bind point, make sure the goto priority expression parameter in the ‘bind’ command is set to ‘NEXT’ or to the next highest priority policy in the list that needs to be executed. This enables other existing rewrite policies to be evaluated along with the new SameSite-related policies.

Conclusion

Citrix ADC’s rewrite policy infrastructure enables you to harden your application cookies by setting appropriate values to the s‘SameSite’ cookie attribute based on application access patterns. Securing the cookies like this will help you improve the security posture of your apps easily, without making changes to your current app deployment.