--- title: "Michael Furman — SameSite Cookies" url: https://appsecpodcast.com/michael-furman-samesite-cookies/ date: 2020-09-03 duration_seconds: 2134 guests: ["Michael Furman"] topics: ["OWASP Top 10", "Vulnerabilities and Exploits"] audio: https://www.buzzsprout.com/1730684/episodes/8122593-michael-furman-samesite-cookies.mp3 video: https://www.youtube.com/watch?v=B0HL_i7BqX0 transcript: true --- # Michael Furman — SameSite Cookies *September 3, 2020 · 36 min* with [Michael Furman](https://appsecpodcast.com/guests/michael-furman/) on [OWASP Top 10](https://appsecpodcast.com/topics/owasp-top-10/), [Vulnerabilities and Exploits](https://appsecpodcast.com/topics/vulnerabilities/) [Audio](https://www.buzzsprout.com/1730684/episodes/8122593-michael-furman-samesite-cookies.mp3) · [Video](https://www.youtube.com/watch?v=B0HL_i7BqX0) ## Show notes Michael Furman is the Lead Security Architect at Tufin, and is responsible for the security and Security Development Lifecycle (SDL) of Tufin software products. Michael is passionate about application security for over 13 years already and evangelizes about application security at various conferences (including OWASP conferences) and security meetups. Michael joins us to break down SameSite cookies, which are all the rage in browsers these days. He describes what they are, the threats they counter, and how SameSite + the Synchronizer Token Pattern work together to counter CSRF. We hope you enjoy this conversation with.... He's worked in this space for 13 years and evangelizes AppSec at various conferences, including OWASP and security meetups. The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/). About Security Journey Michael Furman is the lead security architect at Tufin and is responsible for the security and secure development lifecycle of Tufin software products. → [Learn more about Security Journey](https://www.securityjourney.com/) Connect with Michael Furman: → [Tufin](https://www.tufin.com/) → [Chromium](https://www.chromium.org/Home) Mentioned in this episode: → [Tufin](https://www.tufin.com/) → [Chromium](https://www.chromium.org/Home) Chapters: 00:00 Meet Michael Furman: Michael Furman — SameSite Cookies 02:17 Excellent. And so to get started, what we usually do is 04:54 Yeah, and I'll definitely second what you're saying about application security 07:17 Okay. And so SameSite's been around then for just a couple 08:52 That makes sense in terms of some of the things that 11:19 Yeah, and I think the last I heard for the previous 14:37 So with the— what you're modeling in the test csrf.htm here 17:09 Yeah. So one of the patterns that we've used in the 19:14 It sounds like you could still use the synchronizer pattern, but 30:39 We can only hope and dream that that is a world 32:29 Yeah, that's great. That provides our users with some additional information ## Transcript *4,630 words · assemblyai* **0:00 Chris Romeo:** Michael Furman is the lead security architect at Tufin and is responsible for the security and secure development lifecycle of Tufin software products. Michael is passionate about application security. He's worked in this space for 13 years and evangelizes AppSec at various conferences, including OWASP and security meetups. Michael joins us to break down same-site cookies, which are all the rage in browsers these days. He describes what they are, the threats they counter, and how same-site plus the synchronizer token pattern work together to Counter CSRF. We hope you enjoy this conversation with Michael Furman. You cannot hack yourself secure. Everyone wants to focus on the offensive side of the equation. The challenge is that developers get bored with hacking broken pieces of code after a while. Sure, it's a shiny, cool new thing in the beginning, but how about one year later? At Security Journey, we focus on long-term sustainable security culture with the developers as defenders. Our approach integrates experimentation together with We believe that developers need hands-on experience, but not at the expense of fundamental knowledge. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo or schedule a demo. Hello folks, welcome to another episode of the Application Security Podcast. This is Robert Hurlbut. and glad to be here with you. I'm a threat modeling architect. I'm also joined by my co-host, Chris. Hey, Robert. This is Chris Romeo, CEO of Security Journey, and glad to be here to learn something about same-site cookies, which have gotten a lot of attention over the last 6 months or so. And so I'm excited to dive deep into this. Same here. Definitely so. And so with that in mind, we have our special guest here. Michael Furman, I hope I said that correctly, from Israel. Welcome, Michael. **2:08 Michael Furman:** Thank you. My name is Michael Furman. I am glad to be here. I thank you, you invite me. I will help you and I will help you to explain about same-site cookie. **2:17 Chris Romeo:** Excellent. And so to get started, what we usually do is we ask our guests to give us a little bit of your security origin story, how you got started in this journey on security. Tell us, how did you get started? **2:30 Michael Furman:** It's a great question, and indeed it's a journey. I have started, I think, about 11, almost 12 years ago. I just came to one team in the company called Mercury, and the team leader has asked me, do you want to handle— we have some new framework, the framework called ACG Security. The framework helps our product to handle security. And I say, why not? Because I like, I do like to learn. I do like to understand new issues, new features. And now this framework, by the way, is called Spring Security. It's part of Spring Framework. And this was my beginning of security. And I have started to learn more and more. And why I do like application security? Because required to learn new stuff each day, you know, new attack, new frameworks, new attacks, and it's a great journey. A couple of, about 6-7 years, I work as a lead security architect at Tufin, and I am responsible for SDL, Secure Development Lifecycle. It's also something very great. It allows you to change your company to create secure products. And also required to learn like same-site cookie, like that we have shorter certificate, web certificate. I once again, security is something that you need to learn always. And this is good about security. And before we will continue, a couple of words about Tufin. It's a great company I work for and It's a market leader in security policy automation, and we have a very unique product that helps automate networks for thousands of customers, for a lot of customers. And we do help our customers in on-prem networks, firewalls, cloud, Kubernetes. It's once again a great company, but for me, it's very important that a law gives very significant priority to application security. This is my short story of my journey. **4:53 Chris Romeo:** Yeah, and I'll definitely second what you're saying about application security is certainly something that is changing all the time, and it's an exciting place to be because if you don't like how things are today, just wait a couple of months and things will be different. There'll be new challenges, new problems to solve. And so, our focus for this conversation with Michael is to talk about same-site cookies, but I thought it would be good to start by, let's define what is a same-site cookie for those that might be out there that maybe they're developers, they haven't been doing security for a long time, or they're brand new to security. Let's help them to understand, and us as well, what is a same-site cookie? **5:35 Michael Furman:** Great question. Same-site cookie, it's same-site attribute. Cookie— when a server instructs a client, for example a browser, about a cookie, it sends some attributes. And same site is additional attributes. It's like HTTP only or secure. I guess everyone knows what's secure. Secure attribute means that a cookie will be sent only over HTTPS channel. It will— browser will not send a cookie over HTTP. HTTP only, if a server sends an HTTP-only attribute, in this case a browser will not be able to send it via JavaScript. It's only client-to-server communication. HTTP only, it's also additional attributes. It was introduced by Google, okay, in 2016, and these attributes just instruct a browser It prevents a browser to send a cookie with cross-site requests. Let's say a very common example. It's like you open in one tab your application and the other application, an additional tab on the same browser, open like, for example, forum, and the browser will not be able to send a cookie to additional tab because it's sort cross-site requests. **7:03 Chris Romeo:** Okay. **7:04 Michael Furman:** So it was introduced by Google, by Chrome in 2016 and was adopted by major browsers in end of 2017. Okay. So this is the SameSite attribute. **7:17 Chris Romeo:** Okay. And so SameSite's been around then for just a couple of years or, I mean, was it on the drawing board a few years ago and it's just It seems like it's the last year where same-site has gotten a lot more attention at least. When did Google start even working on this? **7:36 Michael Furman:** Do you know? It's more attention because recently Google has changed and introduced a new policy. By the way, I do like Google and I want to take off my hat and to thank Google, to Chrome, to increasing security in the world. Because, you know, it's a— there's zero project and they do a lot of issues to increase application security. So they have introduced the new policy. It means any cookie, if you have in your application have cookies, so in this case, cookie without any attribute will be treated as cookie of the same site LAX attribute. We will— maybe we will discuss about SameSite in details in a couple of seconds, but the importance of policy is that, let's say, you don't need to do anything and one day you will deploy your application in Chrome and all cookies in your application will be treated as cookies with SameSite attribute. It means it will protect Against the against this sort of attack. **8:51 Chris Romeo:** So that makes sense in terms of some of the things that the reasons why they wanted to put that together. But what are some other things that it's helping you do when you have same site cookies in place? I mean, what is it preventing? What you know again some of the reasons why we needed to have these in place? **9:08 Michael Furman:** Yes. Why Google has introduced this cookie? By what is protect? Same-site cookie protects against CSRF attack. CSRF attack is a very dangerous attack and it was part once, it was part of, you know, of OWASP Top 10. Now it's not in OWASP Top 10 but still it's very important to protect it. And what is CSRF attack? It allows an attacker to perform unwanted operation. Okay. And maybe, you know, we know the expression that one picture worth a thousand words. Maybe I will change it to one demo worth a thousand words. I will be happy to show what is CSRF attack on a very simple example and we will better understand what is it. **10:04 Chris Romeo:** Okay. And before we get there, you said CSRF, so that's client-side request forgery. And you mentioned it's off the top 10. I get that question every so often. Well, it's no longer on the top 10, it must not be an issue anymore. But that's not the case, obviously. **10:22 Michael Furman:** Obviously, but let's say if someone will steal money from your account or will access some very sensitive information in your application, and then you will start to explain to your management, oh, It was only on 11th place. I didn't want to take it, to handle it. I'm not sure that your management will be happy with this answer, and of course customers. I still believe the same. CSRF, it's a very problematic and very dangerous attack that should be prevented. And I do agree that this fact that it was not in OWASP Top 10 It's like severity of the attack, it's maybe not critical, but still it should be handled. **11:19 Chris Romeo:** Yeah, and I think the last I heard for the previous version of the OWASP Top 10, CSRF was actually in the 13th or 14th spot. So it's still relevant, it still exists in applications out there. And I'll just second or third what you guys have already said about the fact that just because it's not in the Top 10, doesn't mean we can just say, oh, we don't really care. We don't, we don't need to worry about it. Like it's still a potential vulnerability in our web applications. And if an attacker can use that to get into our system, I don't care if it's number 117 on the OWASP top list, it's still, it's still a potential usable vulnerability. So Michael, why don't you take us to the demo here and show us how cross-site request forgery actually works? **12:03 Michael Furman:** Okay. I have here a very simple application based on Spring Security. Spring Security, it's a very good framework and I do like it. It solves a lot of issues. And I just take a demo and I will show. It's like bank application. And I came to this, let's say I came in the morning and I want to add banks to my account. **12:30** Okay. **12:30 Michael Furman:** I just performed login with this application, my bank, and now I want to add money to my account. Let's say I have 200, and then I just continue to drink my coffee, and I open newspaper in additional tab. Okay, I just open some additional, and what happens? **12:57** Okay. **12:58 Michael Furman:** Let's— I will go to my account. I see, wow, I have only $100. Where is my money? Where is my money? This money just was stolen by, you know, by CSRF attack. Okay, this is example. In this example, we have the same URL to the same bank. Okay, and What browser tries to do when he tries to access this URL, it just sends a cookie. Let's see it with our network. If I will show it just cookie and after the authentication, we can see that our cookie, this is our cookie, okay? **13:48 Chris Romeo:** Okay. **13:49 Michael Furman:** And it started with AE and finished in 8F. If we will go to this application and we will see that the browser will send the same cookie, AE8F, because this is functionality of browser. Browser knows if you access to this application and a browser having its cookie store a cookie, he will send it. This is a problem. An attacker uses cookie, your authenticated cookie of your authentication that you use to access your bank, and just uses to access and to steal money from your account. This is CSRF attack. **14:37 Chris Romeo:** And so with the— what you're modeling in the test csrf.htm here is That would be like another site where an attacker had control of the content of the HTML and they embedded this evil kind of href call here where it's calling that URL post.html, you know, amount -20. So that would be in this environment, the attacker is in control of another site which has this code embedded within it. Because the attacker compromised the other site. And then when you load that site normally, you end up with that URL being called and your bank balance being deducted. Is that correct? **15:20 Michael Furman:** Yes, absolutely. The attacker, you know, you want to attack, let's say, all banks in the world, and they try to put the correct request to steal money from your account. And then they just wait that you will open login to your bank, okay? And then after you login, they wait you will access to, you know, to some other newspaper or forum or whatever. And this request may be even hidden, you know, you don't have any button, you just open the tab. It was a very simple example, okay? But it just shows that the current functionality without CSRF protection, it's vulnerable, and the application, bank application, is vulnerable to CSRF attack, and attacker will be able to steal money from your account. **16:23 Chris Romeo:** And I think it's important for maybe more seasoned people who might be looking at this and saying, well, you know, that's a pretty simple example and nobody's— no bank's ever gonna expose that level of request in a URL. I think it's important to just say this is a simple example so we can easily understand it. CSRF attacks in the wild are gonna be more complicated, much more complicated than this, but they're gonna use the same basic concept. To pull off the attack. **16:55 Michael Furman:** Absolutely correct. The same concept to steal, you know, information, I would say sensitive information from an application that don't have protection against CSRF attack. **17:09 Chris Romeo:** Yeah. So one of the patterns that we've used in the past to defend against CSRF attacks is the synchronizer token pattern where you're sharing this kind of token back and forth between the server and client. Is that still relevant from your perspective, Michael, as a way to protect against CSRF? **17:28 Michael Furman:** Yes. Yes, it's still valid. It's still a good pattern. It's a pattern that's used in a couple of frameworks, for example, JSF. Okay. It's out of the box. What we have in this, you know, pattern that browser sent cookie and you use some hidden token, something that an attacker don't know, and each form submit this token is just refreshed. This is the reason it's called synchronizer token pattern. So you— an attacker can have access to cookie But an attacker cannot have access to HTTP headers. So it's— and this token should be synchronized every time. So yes, it's very strong pattern, but the problem, it's you need invest a lot to adopt it in— if you have a framework that don't support it. Okay. And, you know, and It's— if it provided out of the box like in JSF, it's great. But if you develop, you know, some API in new modern frameworks like Angular, maybe you want to also to protect against it. And in this case, you need to invest. And in this case, maybe you need to use same-site because same-site is simpler. Okay. And same-site cookie is simpler and also allows protect against CSRF attack. **19:14 Chris Romeo:** So it sounds like you could still use the synchronizer pattern, but as you said, it's just not as universal in terms of availability. It's not built into all frameworks, so you still have to do some work. So tell us a little bit about, maybe you can demo and talk about how does same-site site help us in this situation? **19:33 Michael Furman:** So same-site cookie, as I said before, it prevents from sending cookies to third-party sites, and the new policy that will be enabled very soon will prevent it. Now I just, I have opened configuration of Chrome. Okay, and I just can enable this functionality. Of course, I need to restart the browser, and I will open it once again. And what will happen now, as I said before, each same-site cookie Each cookie will be treated as cookie with same-site attribute. Let's try to access our bank once again. Okay, and let's try to attack. And if you will look, you see once again we have magic. Only by changing the behavior of a browser to to handle, to apply new policy, to handle all cookies as same-site cookie, we have protected our application against CSRF attack. Very important, I did not change anything in my application. I just have applied new policy. This policy will be applied, by the way, will be applied very soon. It was planned to be applied in Chrome 18, and it will be applied in Chrome 84. Why? Because of COVID-19. The COVID-19, you know, has a lot of impact on the world, but even on same site, it also has some impact. It's the policy that Chrome policy will be postponed to 84. But let's see, let's see the difference. Very interesting to see the behavior. If I will see, and I will try to see once again our cookie, the same cookie AE8F, and now let's see what happens if I will try to see an attack, okay, on attacker side. And we can see that The cookie is not sent and we need to— it's redirected to login page. You see, browser don't send a cookie to third-party site and an attacker need to authenticate once again. And once again, we do suppose that an attacker don't know our credentials. He just try to use the authenticated session, authenticated cookie. **22:35 Chris Romeo:** Okay. **22:37 Michael Furman:** Okay, this is the reason that I say that same-site cookie just save our world from CSRF attack. It's like this way. Maybe I will elaborate that same-site cookie has couple of values. Okay, the first value is lux. Lux, it's like, it's It fits almost the use case. It means it provides very good level of security and you don't have a very serious UX impact, user experience impact. It means that you will be able to have links from one application to another, okay, if you want to do it via GET, okay. But in case of like CSRF kind of request. In case of POST request, you will not be able to access other site. But once again, it's— we want to save the problem and we want to provide good UX, so we— it's better to use likes. And when it's— it will be used by default by Chrome when you will enable the policy. or when Google will enforce it. A couple of comments regarding other browsers, and we can see it in this great site, Can I Use. And the SameSite cookie by default was implemented in many browsers. If— and by the way, the colors, green means it's implemented at a very good level, red, of course, it's not implemented. **24:23** Okay. **24:23 Michael Furman:** Okay, if you will see what there is implemented default to LAX, as I said, it will be implemented in Chrome, will be implemented in Edge since Chrome uses Chromium engine, okay, but it will not be implemented in Internet Explorer or Firefox. In Firefox, you will be able to implement it by configuration change, okay, like similar as we do in Chrome. We have different configuration page in Firefox and you will be able to configure Firefox to use SameSite. Now I will back to attributes. It's additional attributes, it's called strict. Okay, strict, it's like very strict attributes. In case of strict, browser will not send a cookie even via HTTP GET. It means, let's say you have a link, you will have authenticated to your bank or, you know, to GitLab or your application and just press link and your browser will open a new tab and you still will need to authenticate. Maybe it's good for, you know, for banks or very sensitive products. **25:44** Yeah. **25:45 Michael Furman:** But you need to know that you have strict option, but you need to use it only in case of very sensitive application. Okay, and one additional attribute that was added in the new policy was none. What is none? It's like before. It's like cookie without SameSite attribute. And when you need to do it, I just would say it's like last resort. I mean, if you— because new policy will be applied soon and you need to change your application and maybe you don't have time to change your application, in this case you need to configure your cookie SameSite=None to be able to behave like before. You know, like maybe you have like meshed a lot of applications on your site and you will try to apply it and to launch it in new Chrome, it will stop to work. So first of all, it's business. In this case, maybe you will need to configure SameSite None because, you know, your application will stop to work. In this case, you have only 2 caveats. First of all, SameSite None will work only with HTTPS. By the way, HTTP is not secure. I hope we will not have any serious applications that work on HTTP. But same-site: none, it's only for HTTPS. The second caveat, you see that it will not— behavior in old version, it's not clear. You know, once again, probably it's not realistic use case that the customer use You know, it's browser that was deployed already, you know, 4 years ago. But still, if you will configure same-site mode and will try to open in Firefox 59 or Chrome 15, the behavior is not unclear. **27:50** Okay? **27:50 Michael Furman:** But these are 3 values on same site. And to summarize, The policy that will be provided very soon, where is it? It will be by default to LAX. It means very good level of security with good user experience. **28:16 Chris Romeo:** If I was to summarize our solution here for cross-site request forgery, I think what we're saying is the synchronizer token pattern plus SameSite together is going to give us defense in depth. It's going to give us multiple layers of protection against one type of vulnerability. And it sounds like CSRF should be— with these 2 things working together, CSRF should be something that kind of disappears from the vulnerability ecosystem. **28:47 Michael Furman:** Absolutely. Then I just absolutely agree with you. Same-site cookie, the synchronizer token pattern, and you can sleep, you know, well, and you don't— will not have CSRF. But as we have discussed in the beginning, we will have new threats, but at least for this one, we can sleep. **29:11 Chris Romeo:** Michael, you got anything for SQL injection? I mean, this is such a good solution. to eliminate something that used to be on the OWASP Top 10. I don't know, can you give us another cookie for SQL injection maybe? **29:22 Michael Furman:** I will take off my hat once again if Google will provide some attributes that will resolve SQL injection problem. As we know, SQL injection, it's on server side, it's more difficult to to resolve. But definitely, it's, you know, I would say regarding additional interesting issues that was added to OWASP Top 10, it's like serialization. And serialization, it's a very happy, I would say, vulnerability. And according to my memory, CTO of Oracle, said that adding serialization to Java was one of the biggest mistakes in Java. And it's like about 40% of vulnerabilities are caused by serialization. And this is— it will be very good that we also for serialization, for SQL injection, because we have like same SQL or same serialization attribute, that will resolve our problem, but— **30:38 Chris Romeo:** We can only hope and dream that that is a world that we get to in the future. So, where— is there any resources that you would point folks to? I know we looked at caniuse.com, which I think is a great resource to help you understand security capabilities of individual browsers. So that's certainly one resource. Any other resources that you would point people to as they're trying to understand Same site as a concept? **31:06 Michael Furman:** Yes, I will try to, you know, as a couple of words about me, I do have a post, a blog, and I try to do a lot of issues related to security, WireGuard, Ghost Tunnel, everything related to security, Istio, Keycloak, a lot of posts. Okay, and if you'll go to same site, I have tried to put a lot of resources here and from OSP and from Chrome and wait a second and I believe that like say Google will provide a lot of information but there is a lot of information in my site And you can see what supported setting before, what is now, what is new cookie policy. I have tried to put everything here and once again this is very good blog of Chromium and it's like Chrome Chromium blog is very, you know, wait a second here. SameSite updates. This is a lot of information I just get from here. **32:29 Chris Romeo:** Yeah, that's great. That provides our users with some additional information for those that want to dive in and understand more about SameSite cookies. So that's definitely great. Michael, do you have any key takeaway or call to action here? Like if you could give our users like 1 or 2 sentences of action, What are you going to call them to do? **32:52 Michael Furman:** I would say the following. Tomorrow when you will come and you will wash your hands and you will wear your masks, I strongly recommend to test your application if it will work in the new policy. Just go to Chrome and configure the same site and try to open and to handle all use cases in your application because it will come and, you know, just enable it here and ensure that all applications work in all cases. In this case, you know, when it will come in, you know, in a couple of months, you will be sure that your application works very good. The second This activity that we did in our company, we have enabled the cookie out of the box in the proactive way. We have configured logs because it's— in this case, we don't need to be dependent on browser configuration. So if you can't configure your cookies to SameSite=Lax or to SameSite=Strict, depending on your application, then in this case you will be protected in all browsers in a very simple way, with very good security. So from my point of view, 2 action items: test in Chrome when policy enabled and configure your cookies with SameSite=Lax. **34:31 Chris Romeo:** Great advice. Thank you, Michael. Really appreciate you being here with us today. Learned a lot more about SameSite cookies and how we can put a little bit more security within our websites and think about request forgery and try to protect against it. So thank you very much. **34:50 Michael Furman:** I want to thank you. It was my pleasure to explain and take care and good luck in every issue. Thanks, Michael. **34:59** Thanks, Michael. **35:01 Chris Romeo:** Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @RobertHurlbut. Remember, security is a journey, not a destination. --- Source: https://appsecpodcast.com/michael-furman-samesite-cookies/