How to quickly resolve samesite cookie issues, at least until a CF update helps handle it more automatically.
The update from Adobe yesterday (Mar 17, 2020) did not include a fix regarding the long-anticipated “samesite cookie” problem. In this post, I will share info on what you can do in the meantime, until Adobe DOES address the problem. (The info will also help any who happen to be running on CF11 or earlier, which are no longer updated by Adobe.)
Wasn’t Adobe due to fix this in “the next update”?
Before explaining the issue briefly, and the fix you can consider for now, let me note that it’s something that Chrome announced in May 2019 would be implemented in its version 80, which did come out recently, making the matter all the more pressing. And many in the CF community have been asking Adobe to address this for as long. And Adobe had said there that a fix would be coming in “q2 2020”, while in still other places the implication was that it would be coming in “the next update”.
So when the CF update was released yesterday, implementing an important security fix (regarding a vulnerability in the Tomcat web server/AJP connector), many had been expecting it would add the samesite cookie fix. It did not.
So again, I am writing here to point you to resources that explain the problem and a fix.
What is the SameSite Cookie issue?
Fortunately, a lot has been written about the issue, as has been observed by those who knew the problem was coming. If you simply google the term now, you will find ample resources to explain what it’s about. Here are some:
-
https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/
- https://blog.chromium.org/2019/10/developers-get-ready-for-new.html
- https://webmasters.googleblog.com/2020/01/get-ready-for-new-samesitenone-secure.html
- And many more
But bottom line, it has to do with when your site may send users pages that involve communication with other sites (or other applications within your own CF site), and where the cookies set by those other sites/apps don’t honor this “same site” cookie setting that Chrome now requires. And so Chrome (and soon other browsers) see this as a problem, and so your app may fail or have errors or just function improperly.
Eventually, Adobe will come out with a fix for CF so that it (CF, at least) DOES set those samesite cookie settings, either with some better default or with the option for you to control the settings.
What can you do, until Adobe does fix the SameSite Cookie issue?
Until a CF update DOES address the problem, you are not “stuck”. You can instead leverage the fact that your web server (IIS or Apache, typically used with CF) both offer a “rewrite” feature, and while normally folks think of that for controlling/changing incoming requests, such rewrite features can ALSO be used to control handling of incoming/request AND outgoing/response HEADERS. And cookies are in fact set as response headers.
And thankfully, our own CF security guru (and all-around great guy) Pete Freitag blogged about all this some months ago. Indeed, first in 2018! And he shows in his two blog posts how to handle this in IIS and Apache, respectively:
Again, this info will also help those on CF11 or older CF versions (or other older CFML engines, or indeed non-CFML app servers) that may also not have implemented samesite cookie support.
There’s also a user defined function that James Moberg has offered.
For more blog content from Charlie Arehart, see his posts here as well as his posts at carehart.org. And follow him on Twitter and other social media as carehart.
Hope that’s helpful. I have helped or seen discussions from many people who did not seem to know of these alternativess, or perhaps even of this issue (though it’s getting harder to ignore as more people move to Chrome 80), so I felt it was worth pointing out specially here.
Danny, yes, this was indeed finally rolled into official updates in Apr 2020, in both CF2018 update 9 and CF 2016 update 15.
First, it added a this.sessioncookie.samesite for application.cfc (along with also a this.authcookie.samesite), as well as the same for the sessioncookie and authocookie attributes of cfapplication, and also a samesite attribute for cfcookie.
For more details, see the technote for each update, https://helpx.adobe.com/coldfusion/kb/coldfusion-2018-update-9.html, and https://helpx.adobe.com/coldfusion/kb/coldfusion-2016-update-15.html.
Second, yes, it did also add a change in the CF Admin: the “memory variables” page now has an option at the bottom for “Cookie Samesite default value”, which affects the session cookies that CF creates (for session vars and client vars). It sets the default for the CF instance, unless overridden by the app-level controls mentioned in my last comment.
And to be clear, that setting as well as those CFML options above all support values of strict, lax, and none.
Hi Charlie,
Has there been any update on this topic? I was assuming there’d be a new administrator setting to control the SameSite setting of the jsessionid cookie, but I’m not aware of such a setting. Is it still the case the web server Header rewriting solutions are the only way to go here?
Google has announced on Apr 5 that they are rolling back the recent more stringent samesite cookie requirements in Chrome, at least to later summer 2020. For more, see https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html
That gives us a bit of a reprieve, as we await Adobe adding built in support for them. Of course, there could still be negative impact in the meantime, either for users who don’t yet upgrade Chrome (to remove protections added in previous updates), as well as for other browsers implementing samesite cookie protections.
Adobe posted a short-term fix available for CF2018 and CF2016, as discussed in comments of the bug report that I’d linked to above, https://tracker.adobe.com/#/view/CF-4201688. See the ones dated from today (Mar 24, 2020), and forward.
We can hope that based on feedback, they will roll these changes into a later official CF update.
You must be logged in to post a comment.